Puis-je contrôler l'emplacement des paramètres utilisateur .NET pour éviter de perdre des paramètres lors de la mise à niveau de l'application?
https://stackoverflow.com/questions/621265
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'essaie de personnaliser l'emplacement du fichier user.config. Actuellement, il est stocké avec un hachage et un numéro de version
%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\
Je veux qu'il soit agnostique par rapport à la version de l'application
%AppData%\[CompanyName]\[ProductName]\
Cela peut-il être fait et comment? Quelles sont les implications? L'utilisateur perdra-t-il ses paramètres de la version précédente après la mise à niveau?
La solution
Pour répondre à la première question, vous pouvez techniquement placer le fichier où vous voulez, mais vous devrez le coder vous-même, car l'emplacement par défaut du fichier est le premier de vos deux exemples. ( lien permettant de le faire vous-même )
En ce qui concerne la deuxième question, cela dépend de la manière dont vous déployez l'application. Si vous déployez via un fichier .msi, il y a alors deux hachages dans les propriétés du projet d'installation (à partir duquel le msi est construit), le "code de mise à niveau" et le "code de produit". Celles-ci déterminent comment le MSI peut être installé et s'il met à niveau, écrase ou installe à côté d'une autre version de la même application.
Par exemple, si vous avez deux versions de votre logiciel et qu'elles ont des codes de «mise à niveau» différents, alors pour Windows, ce sont des logiciels complètement différents, quel que soit leur nom. Toutefois, si le code de «mise à niveau» est le même, mais que le code de «produit» est différent, lorsque vous essayez d'installer le 2nd MSI, il vous demande si vous souhaitez effectuer une mise à niveau. Il est alors censé copier les valeurs du fichier. ancienne config à une nouvelle config. Si les deux valeurs sont identiques et que le numéro de version n'a pas changé, la nouvelle configuration se trouvera au même emplacement que l'ancienne et ne nécessitera rien. Documentation MSDN
ClickOnce est un peu différent, car il est plus basé sur le numéro de version de ClickOnce et le chemin de l'URL. Cependant, j'ai constaté que tant que vous continuez à "Publier" au même emplacement, la nouvelle version de l'application continue. utiliser la configuration existante. ( lien permettant à ClickOnce de gérer les mises à jour . )
Je sais aussi qu’il existe un moyen de fusionner manuellement les configurations lors de l’installation du msi à l’aide de scripts d’installation personnalisés, mais je ne me souviens pas des étapes à suivre pour le faire ... (voir ce lien pour savoir comment procéder avec un fichier web.config)
Autres conseils
Je voulais ajouter ce texte cité comme référence pour avoir ce problème à l'avenir. Vous pouvez apparemment demander à l'infrastructure ApplicationSettings de copier les paramètres d'une version précédente en appelant Mettre à niveau :
Properties.Settings.Value.Upgrade();
De la FAQ sur les paramètres du client , article de blog: ( archive )
Q: Pourquoi y a-t-il un numéro de version dans le chemin user.config? Si je déploie une nouvelle version de mon application, l’utilisateur ne perdra-t-il pas tous les paramètres enregistrés par la version précédente?
R: Il y a plusieurs raisons pour lesquelles le Le chemin utilisateur.config est sensible à la version.
(1) Pour prendre en charge le déploiement côte à côte de différentes versions d'un application (vous pouvez le faire avec Cliquez une fois, par exemple). Il est possible pour une version différente du application d'avoir différents paramètres sauvé.
(2) Lorsque vous mettez à niveau un application, la classe de paramètres peut ont été modifiés et peuvent ne pas être compatible avec ce qui est sauvegardé, ce qui peut entraîner des problèmes.
Cependant, nous avons facilité la tâche mettre à jour les paramètres d'un précédent version de l'application au dernier. Il suffit d'appeler ApplicationSettingsBase.Upgrade () et il va récupérer les paramètres de la version précédente qui correspond à la version actuelle de la classe et du magasin les sortir dans la version actuelle de fichier user.config. Vous avez aussi le possibilité de remplacer ce comportement soit dans votre classe de paramètres ou dans votre implémentation fournisseur.
Q: D'accord, mais comment savoir quand appeler la mise à niveau?
R: Bonne question. En un clic, quand vous installez une nouvelle version de votre application, ApplicationSettingsBase va le détecter et automatiquement mise à niveau des paramètres pour vous au point les paramètres sont chargés. En non-clic cas, il n'y a pas de mise à niveau automatique - vous devez appeler vous-même la mise à niveau. Voici une idée pour déterminer quand appeler Upgrade:
Avoir un paramètre booléen appelé CallUpgrade et lui donner une valeur par défaut valeur de true. Quand votre application démarre up, vous pouvez faire quelque chose comme:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
Cela garantira que Upgrade () est appelé seulement la première fois le l'application s'exécute après une nouvelle version est déployé.
Je ne crois pas une seconde que cela puisse réellement fonctionner - Microsoft ne fournirait pas cette possibilité, mais la méthode est la même.
Le fichier user.config est stocké sur
c:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<verison>
<c:\Documents and Settings> est le répertoire de données de l'utilisateur, non itinérant (Paramètres locaux ci-dessus) ou itinérant.
<username> est le nom d'utilisateur.
<companyname> est la valeur CompanyNameAttribute, si disponible. Sinon, ignorez cet élément.
<appdomainname> est le AppDomain.CurrentDomain.FriendlyName. La valeur par défaut est généralement le nom de fichier .exe.
<eid> est l'URL, le StrongName ou le chemin d'accès, en fonction des preuves disponibles pour le hachage.
<hash> est un hachage SHA1 d'éléments de preuve provenant du domaine CurrentDomain, dans l'ordre de préférence suivant:
1. StrongName
2. URL:
Si aucun de ces éléments n'est disponible, utilisez le chemin d'accès .exe.
<version> correspond au paramètre AssemblyVersionAttribute de AssemblyInfo.
La description complète est ici http://msdn.microsoft.com/en-us/library /ms379611.aspx
(J'ajouterais ceci comme commentaire à la réponse de @Amr, mais je n'ai pas assez de représentant pour le faire pour le moment.)
Les informations contenues dans l'article MSDN sont très claires et semblent toujours appliquer. Cependant, il est omis de mentionner que le hachage SHA1 est écrit en base 32, plutôt qu’en base 16.
Je pense que l'algorithme utilisé est implémenté dans ToBase32StringSuitableForDirName, qui peuvent être trouvés ici dans la source de référence Microsoft .
