2009-06-15 6 views
3

Depuis quelques mois, j'ai des problèmes avec mon app.config. Je vais ajouter une clé AppSetting et exécuter mon projet sans réel problème, il lit le fichier de configuration et tout est bon. Ensuite, à une date ultérieure, je vais changer la valeur de cette même clé et quand je cours mon projet, j'obtiendrai l'ancienne valeur de la clé. Il semble que ce n'est pas en enregistrant correctement le fichier ou en détectant qu'il y avait un changement dans le fichier app.config. Si je nettoie ou reconstruis ma solution, ça va. Quelqu'un d'autre a-t-il déjà vu ce problème? Y a-t-il une solution à chaud? C'est un vrai problème de devoir vérifier tout le temps surtout quand les clés sont généralement la différence entre les environnements de production et de test. Imaginez ma surprise quand j'ai commencé à publier des messages de test dans mon environnement de production, effrayant.Visual Studio 2008 App.config Mise en cache

Merci à l'avance

Répondre

0

la dernière sp de vs 2008 semble magiquement résolu mon problème, bien que je ne vois pas en note

0

Votre app.config est copié dans le bac/debug ou bin/dossier de sortie lorsque vous compilez. Si vous changez votre app.config dans votre dossier source, mais ne recompilez pas, la modification ne sera pas propagée. Vous devez reconstruire pour le déplacer dans le dossier où le code est réellement en cours d'exécution.

Vous pouvez également modifier le fichier bin/Debug/app.config à la place.

Je ne pense pas que ce soit le cas qu'une nouvelle construction est nécessaire, chaque fois que je le compiler doit vérifier que le fichier et si les modifications, puis copiez-le. Mais je ne peux pas imaginer que chaque fois que je faire une modification que je devrais faire une reconstruction pour le compilateur à reconnaître mes changements. Reconstruire vs construire reconstruisent fixe mon problème et recompile toute la production alors qu'une accumulation de mes vérifie la compréhension de tout changement à tous les fichiers et versions uniquement les fichiers

Vous ne devriez pas avoir à nettoyer/reconstruire, mais recompilez simplement (F6 plutôt que Build -> RebuildSolution) pour que le fichier app.config soit propagé. Mais à tout le moins, votre code doit être recompilé.

Je me demande ... est-il possible que vous ayez votre propriété "Copy To Output Directory" pour le fichier app.config réglé sur "Do not copy"? Pour vérifier: cliquez avec le bouton droit sur app.config dans l'Explorateur de solutions, cliquez sur Propriétés.

+0

Je ne pense pas que ce soit le cas qu'une nouvelle construction est nécessaire, chaque fois que je le compiler doit vérifier ce fichier et si les modifications, puis le copier. Mais je ne peux pas imaginer que chaque fois que je fais un changement que je devrais faire une reconstruction pour le compilateur pour reconnaître mes changements. Reconstruire vs construire reconstruire résout mon problème et recompile toutes les sorties alors qu'une construction de ma compréhension vérifie les changements à tous les fichiers et ne libère que ces fichiers –

+0

app.config est toujours réglé sur "ne pas copier" il est interne construire le script en vs qui l'envoie à la sortie dir sous appname.exe.config si je devais copier dans le répertoire de sortie il sortirait comme app.config et ne serait pas référencé ou utilisé par l'exe –

+0

Bon point. J'étais vraiment juste en train de saisir les pailles.Je n'ai jamais eu le problème que vous rencontrez. Voici un autre coup dans le noir: votre projet est multithread ou multi-processus et certains threads/processus ne sont pas arrêtés et/ou redémarrés lorsque vous relancez votre projet. Comme app.config est seulement lu au démarrage, les anciennes valeurs sont donc toujours en mémoire lorsqu'elles sont lues par le programme en cours d'exécution. – Randolpho

0

Alternativley êtes-vous sûr que vous modifiez le droit app.config: o

-vous fonctionner en mode administrateur?