Lors du débogage de mon projet dans Visual Studio 2008, mon fichier Paramètres.Settings conserve la réinitialisation entre les constructions. Y a-t-il un moyen d'empêcher cela de se produire? p>
merci. p>
4 Réponses :
En plus du haut de ma tête, je pense que vous pouvez définir dans les propriétés du fichier (dans Visual Studio avec le bouton droit de la souris sur les propriétés) une option "Ne pas copier" lorsque le projet est construit / exécuté. Ce qui se passe probablement est probablement lorsque votre projet est construit, le fichier de paramètres est copié dans le répertoire BIN DEBUG, écrasant le fichier de paramètres de l'exécution précédent. P>
Je viens de vérifier cette option et il est déjà défini sur "Ne pas copier".
Je crois que les paramètres.Settings Les fichiers sont enregistrés en fonction du numéro de version actuel, essentiellement en tant que "fonctionnalité" où les paramètres ne sont pas enregistrés entre les versions différentes du même programme sur une machine. En supposant que vous incrémentez automatiquement le numéro de version lors de la compilation (1.0. * Dans AssemblyInfo.cs), vous réinitialiserez vos paramètres à chaque fois que vous compilez une nouvelle version. P>
Pour corriger cela, le meilleur cours serait de sérialiser votre propre fichier de paramètres dans le répertoire de données d'application. P>
Je ne sais pas comment cela serait considéré comme une fonctionnalité de Microsoft. Pouvez-vous imaginer toutes les plaintes qu'il y aurait chaque fois que Microsoft a mis à jour votre logiciel? Pourquoi penseraient-ils que ce serait différent des développeurs "américains"? :) Merci pour votre réponse!
Ce n'est pas un problème si vous mettez à jour vos numéros de version manuellement. Le résultat final est que l'utilisateur peut installer des versions 1.0, 1.5, 1.7 et 2.0 de votre logiciel, et ils auront chacun leurs propres paramètres uniques enregistrés. Pour les paramètres étant partagés entre ces 4 applications, vous devez enregistrer votre propre fichier de paramètres dans un emplacement partagé.
Je n'ai jamais aimé le comportement de l'une des fonctionnalités de paramétrage de l'application fournies par MS. Il a honte parce qu'il semble y avoir beaucoup de cadre là-bas, mais je trouve plus facile de préparer le mien.
D'accord, j'ai découvert la réponse que je cherchais vraiment. Fondamentalement, vous devez appeler localfileSettingsProvider.upgrade. Cependant, étant donné que je déploierai-je à l'aide de ClickOnce, cela le fera automatiquement.
Q: D'accord, mais comment puis-je savoir quand appeler la mise à niveau? P>
A: Bonne question. Dans ClickOnce, lorsque vous installez une nouvelle version de votre application, les applicationsSettingsbase le détecteront et mettront automatiquement les paramètres de mise à niveau pour vous aux paramètres de points sont chargés. Dans les cas autres que ClickOnce, il n'y a pas de mise à niveau automatique - vous devez appeler vous-même. Voici une idée pour déterminer quand appeler la mise à niveau: p>
avoir un paramètre booléen appelé CallupGrade et lui donner une valeur par défaut de vrai. Lorsque votre application démarre, vous pouvez faire quelque chose comme: p> Cela garantira que la mise à niveau () est appelée que la première fois que l'application s'exécute après la déploiement d'une nouvelle version. P> ref: http://blogs.msdn.com/rprabhu/ Articles / 433979.aspx P> P>
Grande idée, merci! Vous devez également vous assurer d'appeler Save ()
Parmi d'autres raisons, le fichier de paramètres permet de réinitialiser chaque fois que vous avez débogué simplement parce que la prochaine fois que vous avez débogué, vous serez en mesure de tester l'ensemble de l'application. Ne pas réinitialiser les paramètres peut conduire à des bugs non détectés. P>