Puis-je contrôler l’emplacement des paramètres utilisateur .NET pour éviter de perdre des paramètres de mise à niveau de l’application ?

Question

Je suis en train de personnaliser l’emplacement de la `` fichier. Actuellement, elle est stockée avec un nombre de version et de hash

J’ai envie d’elle être agnostique à la version de l’application

Est-ce possible et comment ? Quelles sont les implications ? L’utilisateur perdront leurs paramètres de la version précédente après la mise à niveau ?

Answer 1

Je voulais ajouter ce texte cité comme une référence pour quand j'ai ce problème à l'avenir. Soi-disant, vous pouvez demander à l'ApplicationSettings infrastructure pour copier les paramètres à partir d'une version précédente en appelant la Mise à niveau:

Properties.Settings.Value.Upgrade();

À partir des Paramètres du Client FAQ blog:

Q: Pourquoi est-il un numéro de version de l'utilisateur.chemin du fichier de configuration? Si je le déploiement d'une nouvelle version de mon application, ne sont pas à l'utilisateur de perdre tous les paramètres enregistrés par la version précédente?

R: Il y A plusieurs raisons qui expliquent pourquoi l' de l'utilisateur.chemin du fichier de configuration est la version sensibles.

(1) À l'appui de side-by-side de déploiement de différentes versions d'un application (vous pouvez le faire avec Clickonce, par exemple). Il est possible pour les différentes version de la application pour avoir des paramètres différents sauvegardées.

(2) Lorsque vous mettez à niveau un application, les paramètres de la classe ont été modifiées et ne peuvent être compatible avec ce qui est enregistré, ce qui peut conduire à des problèmes.

Cependant, nous avons rendu facile pour paramètres de mise à niveau à partir d'une précédente version de l'application de la plus tard. Appelez simplement ApplicationSettingsBase.Mise à jour()et il va récupérer les paramètres de la précédente version qui correspond à la version actuelle de la classe et de les stocker dans la version actuelle de l' de l'utilisateur.fichier de configuration. Vous avez également la option de substitution de ce comportement soit dans les paramètres de votre classe ou dans votre fournisseur de mise en œuvre.

Q: d'Accord, mais comment puis-je savoir quand appel de Mise à niveau?

Une: Bonne question. Dans Clickonce, lorsque vous installez une nouvelle version de votre application, ApplicationSettingsBase le détectera automatiquement et paramètres de mise à niveau pour vous à l'endroit les paramètres sont chargés. Non Clickonce cas, il n'y a pas de mise à niveau automatique - vous devez appeler pour vous mettre à niveau. Voici une idée pour déterminer quand à l'appel de Mise à niveau:

Avoir un paramètre booléen appelé CallUpgrade et de lui donner une valeur par défaut la valeur true. Lorsque votre application démarre en haut, vous pouvez faire quelque chose comme:

if (Properties.Settings.Value.CallUpgrade)
{
   Properties.Settings.Value.Upgrade();
   Properties.Settings.Value.CallUpgrade = false;    
}

Cela permettra d'assurer que la Mise à jour() est appelé seulement la première fois la l'application s'exécute après une nouvelle version est déployé.

je ne crois pas une seconde qu'il pourrait effectivement le travail - il n'y a aucun moyen de Microsoft serait offrent cette possibilité, mais la méthode est le même.

Answer 2

Pour répondre à la première question, vous techniquement pouvez mettre le fichier où vous le souhaitez, cependant, vous aurez à coder vous-même, comme l'endroit par défaut le fichier va est le premier de vos deux exemples. (lien pour comment faire vous-même)

Quant à la deuxième question, cela dépend de comment vous déployez l'application. Si vous déployez via un .msi, puis il y a deux hachages dans les propriétés du projet d'installation (que la msi est construit à partir), le "code de mise à niveau" et le "code du produit'. Celles-ci déterminent la façon dont le msi peuvent être installés, et si il se met à jour, écrase, ou installe à côté de toutes les autres versions de la même application.

Par exemple, si vous avez deux versions de votre logiciel, et ils ont différents "mise à niveau" les codes, puis à windows, ils sont complètement différents morceaux de logiciel, indépendamment de ce que le nom est. Toutefois, si la "mise à niveau" du code est le même, mais le "produit", le code est différent alors lorsque vous essayez d'installer la 2ème msi, il vous demandera si vous souhaitez mettre à niveau, à laquelle il est censé copier les valeurs de l'ancienne config pour une nouvelle config. Si les deux valeurs sont les mêmes, et le numéro de version n'a pas changé alors la nouvelle configuration sera dans le même emplacement que l'ancienne config, et ne pas avoir à faire quoi que ce soit. La Documentation MSDN

ClickOnce est un peu différent, parce que sa base plus large de la version ClickOnce # et le chemin d'URL, cependant j'ai trouvé que tant que vous continuez à "Publier" à l'emplacement même de la nouvelle version de l'application va continuer à utiliser la configuration existant. (lien pour comment ClickOnce gère les mises à jour)

Je sais aussi qu'il y un moyen de fusionner manuellement les configs lors de l'installation du msi en utilisant des scripts d'installation, mais je ne me souviens pas les étapes exactes pour le faire... (voir ce lien pour savoir comment faire avec un site web.config)

Answer 3

L'utilisateur.fichier de configuration est stocké à

c:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<verison>

<c:\Documents and Settings> est le répertoire des données utilisateur, soit non itinérant (Paramètres Locaux ci-dessus) ou d'itinérance.
<username> est le nom de l'utilisateur.
<companyname> est le CompanyNameAttribute valeur, si disponible. Sinon, ignorez cet élément.
<appdomainname> est le domaine d'application.CurrentDomain.FriendlyName. Ce général par défaut à l' .nom de fichier exe.
<eid> est l'URL, StrongName, ou le Chemin d'accès, sur la base des preuves disponibles de hachage.
<hash> est un hash SHA1 de la preuve recueillie à partir de la CurrentDomain, dans l'ordre de préférence suivant:
1. StrongName
2. URL:
Si aucune de ces options n'est disponible, utilisez la .exe chemin.
<version> est le AssemblyInfo de AssemblyVersionAttribute réglage.

Description complète est ici http://msdn.microsoft.com/en-us/library/ms379611.aspx