Les paramètres.Par défaut.<propriété> renvoie toujours la valeur par défaut au lieu de la valeur en persistant de stockage (fichier XML)

J'ai récemment écrit une DLL en C# (.Net 2.0) qui contient une classe qui nécessite une adresse IP. Un co-travailleur de la mine altération de la classe pour récupérer l'adresse IP à partir d'un ".dll.config" (fichier XML -- Ce qui, apparemment, est généré automatiquement par l'Application "Paramètres" fichier qu'il a créé (Settings1.les paramètres). L'avantage de cette était de permettre à l'utilisateur de changer l'adresse IP dans le fichier XML/fichier de configuration.

Malheureusement, lorsque je vérifie son code de l'arbre, et essayez de compiler (ou d'utilisation) ce nouveau code, toute application à l'appel de cette DLL n'obtient la valeur par défaut, plutôt que de la valeur à partir du fichier.

Le constructeur qui appelle le fichier de configuration ressemble à ceci:

    public class form : System.Windows.Forms.Form
    {
        public form()
        {
            //This call is required by the Windows Form Designer.
            InitializeComponent();
            IP = IPAddress.Parse(Settings1.Default.IPAddress);
        }
    }

J'ai trouvé une référence à ce problème sur les forums MSDN où un utilisateur a dit:

les "anciens" des valeurs (celles que vous définissez au temps de développement) sont codés en dur. Si le franework n'est pas en mesure d'accéder ou d'ouvrir le fichier de config, il utilisera les paramètres par défaut à la place. Ce sera toujours le cas si vous utilisez les paramètres dans une dll.

Est-ce à dire que je ne peut pas stocker une valeur externe d'une DLL dans un fichier de config? (Mon collègue a en quelque sorte fait ce travail...)
Depuis mon cadre n'apparaît pas en mesure d'accéder ou d'ouvrir le fichier de config, comment puis-je savoir pourquoi ça ne fonctionne pas? Ou même de les détecter quand cela se produit?

Decker: Qui aide un peu. Malheureusement, je suis en train d'écrire cette DLL dans un cahier des charges, donc je n'ai pas réellement l'accès à l'Application fichier de configuration. Comme vous l'aurez remarque ci-dessus, mon co-travailleur de la création d'une section "Paramètres de1.paramètres de fichier". Je ne comprenais pas à l'époque, mais il semble maintenant que l'ajout de la "1" ne cesse il de l'paramètres de l'espace de toutes les applications qui l'appelle.

Je crois que je suis à essayer de comprendre est pourquoi la DLL n'a pas l'air de trouver le fichier de config assis à côté de lui dans le même répertoire. Le traçage par le code de l'étape-par-étape ne révèle rien.

En aparté, je peux changer le "Type de Sortie" de mon assemblée de la "Bibliothèque de classes" à "Application Windows" et d'ajouter les lignes suivantes au début de mon code de la DLL:

    [STAThread]
    public static void Main(string[] args)
    {
        System.Windows.Forms.Application.Run(new form());
    }

Lorsque je l'exécute, il génère un autre fichier de config (un ".exe.config") et que je peux le modifier et de l'avoir tirer les nouvelles données à partir du fichier. Donc je suis un peu confus. Des idées?

OriginalL'auteur Pretzel | 2008-10-10

.net application-settings c#dll

2

Je suis régler ce problème précis dans une application que je suis en train de prototypage. Bien que Decker suggestion de piratage des fichiers de config ensemble devrait fonctionner je pense que c'est assez gênant manuel hack pour effectuer dans le cadre d'un cycle de production. Au lieu de cela, j'ai décidé que la solution la plus propre est d'avoir chaque bibliothèque analyser sa propre bibliothèque.dll.fichier de configuration. Son pas encore parfait et il exige un peu de chaudière-plaque de code, mais il semble être le seul moyen de contourner le byzantin façon .Net poignées de l'app.les fichiers de configuration.

Je vais vous donner le prix ici, car c'est ce que mon équipe a fini par faire.
Comme une note pour les futurs visiteurs de cette question: vérifiez si vous avez récemment changé votre espace de noms par défaut. Le nœud XML lui-même correspond à l'espace de noms pour vos biens et de vos paramètres. Si vous mettez à jour votre espace de noms par défaut et de ne pas mettre à jour le fichier XML, il silencieusement tomber en arrière, les valeurs par défaut dans le .fichier de paramètres au lieu de lancer une erreur.

OriginalL'auteur bouvard
6

J'utilise cette technique de tous les temps en temps. Souvent, j'ai une bibliothèque de l'assemblée qui exige que certains paramètres, et j'ai besoin de définir à la fois par les projets d'essais ainsi que les principaux "exécutable" assemblées ont-ils des projets web ou Windows des projets de service.

Vous avez raison en ce que lorsque vous créez un fichier de paramètres pour tout projet, il ajoute un fichier de config. La valeur que vous entrez pour n'importe quel paramètre est stocké dans deux endroits: le fichier de config ET dans les attributs sur les classes créées par les paramètres de l'infrastructure. Lorsqu'un fichier de config n'est pas trouvé, les valeurs ancrées dans les attributs sont utilisés.

Voici un extrait qui montre un tel attribut:

Voici un extrait qui montre la valeur par défaut de la ConcordanceServicesEndpointName dans la classe générée:
```
    [global::System.Configuration.ApplicationScopedSettingAttribute()]
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
    [global::System.Configuration.DefaultSettingValueAttribute("InternalTCP")]

    public string ConcordanceServicesEndpointName {
        get {
            return ((string)(this["ConcordanceServicesEndpointName"]));
        }
    }
```
Ce que vous voulez faire est de copier la section de configuration de l'application.fichier de configuration de la bibliothèque de l'assemblée du projet et de les fusionner (avec précaution) dans le web.config ou app.config pour l'assemblage principal. Au moment de l'exécution, c'est le seul fichier de configuration est utilisé.

Voici un exemple:
```
<configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="LitigationPortal.Documents.BLL.DocumentsBLLSettings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <LitigationPortal.Documents.BLL.DocumentsBLLSettings>
      <setting name="ConcordanceServicesEndpointName" serializeAs="String">
        <value>InternalTCP</value>
      </setting>
    </KayeScholer.LitigationPortal.Documents.BLL.DocumentsBLLSettings>
  </applicationSettings>
```
Vous devez copier ces articles dans le "vrai" fichier de config.

Je pense que c'est la bonne réponse, et la meilleure façon de le faire. Pour moi, il est logique que les paramètres affectant la demande doit être dans le même fichier de configuration principal plutôt que de les étaler sur N les différents fichiers de configuration. Je ne pense pas que c'est gênant dans le cadre du cycle de production. Lorsque vous faites référence à une dll et réalisez que vous avez besoin pour être en mesure de modifier certains paramètres sur elle, vous les ajoutez à votre application.config ou web.config. Et vous avez terminé. Juste être prudent avec les configSections partie lors de la fusion.

OriginalL'auteur Howard Pinsley
2

J'ai eu ce même problème pour une longue période de temps - c'est ennuyeux.

J'aime l'idée de faire votre propre fichier de configuration et d'avoir chaque DLL analyser, mais il pourrait être facile de manquer d'avoir à modifier le fichier config.

Une chose que j'ai fait dans le passé pour au moins les rendre un peu plus facile est de s'assurer que toute config de valeurs que l'Setting1.Fichier de paramètres ne sont pas valides.

Par exemple, j'ai une classe qui utilise LINQ-to-SQL pour parler de la DB. Il a donc un Setting1.fichier de paramètres qu'il stocke la chaîne de connexion à la base de données. La valeur par défaut qui est entré (à glisser-déposer les tables de base de données dans le concepteur) est la chaîne de connexion de la dev base de données.

Une fois que j'ai le fichier DBML créé en dehors de la base de données de test, je peux y aller et de modifier les Paramètres du fichier et saisissez un nom de base de données comme "FAKE_DATABASE".

De cette façon, si vous utilisez DLL dans un autre projet, et de l'oublier pour fusionner les fichiers de configuration pour ajouter à la bonne config de la valeur pour la DLL, au moins vous aurez une erreur en disant quelque chose comme "Ne peut pas se connecter à FAKE_DATABASE".

Bien sûr, si vous avez à travailler avec le concepteur de nouveau, vous aurez à changer la valeur de retour de la valeur de votre dev base de données.

Immense douleur. Ils ont obtenu de modifier ce en quelque sorte.

+1 pour le monde réel exp.

OriginalL'auteur Sam Schutte
1

Apparemment, votre application est en train d'essayer de lire le fichier de configuration par défaut (ce qui est probablement la demande de fichier de configuration). Pour s'en assurer, ajoutez la paire clé-valeur dans la dll de fichier de configuration à la demande de fichier de configuration, exécutez l'application et voir si elle est à lire en ce moment.

J'ai ajouté la même paire clé-valeur à partir de la DLL de l'application du fichier de config, mais l'application indique toujours la valeur par défaut à partir de la DLL (plutôt que la valeur contenue dans la DLL .dll.fichier de configuration.) 🙁

OriginalL'auteur Serhat Ozgel
1

Je pense que je viens de trouver une explication de pourquoi cela ne fonctionne pas pour ma DLL et mon test de l'application. Voici la conclusion d'exception à partir de certains le blog de guy:

Le correctif de ce soit de s'assurer que votre application et le soutien assemblées ont le même espace de noms ou assurez-vous de fusionner le contenu de AppName.exe.config et DllName.dll.config (oui lorsque vous compilez un .dll maintenant, il génère ce fichier, mais il est ignoré si vous le copiez dans le répertoire de l'application et n'est pas automatiquement fusionnés)

Donc, soit je dois garder la DLL et l'Application dans le même espace de noms -ou - j'ai pour fusionner le contenu de la DLL fichier de configuration le fichier de configuration de l'Application.

(N'a pas ce genre de défaites le but de la DLL? J'ai pensé à une DLL qui était censé être une bibliothèque indépendante.)

C'est peut-être pourquoi il fonctionne pour mon collègue. La production de l'application partage le même espace de noms que la DLL. (Mon appli de test n'a clairement pas...)

Mise à JOUR: je me suis assis avec mon collègue récemment et a parlé de ce problème à nouveau, et il semble qu'il n'a jamais été à travailler pour lui, mais il n'avait pas réalisé parce qu'il avait définir la valeur initiale d'être le même que le dispositif que nous avons essayé d'utiliser. Alors bien sûr, il est apparu à travailler au premier abord, mais dès que nous avons déployé ailleurs légèrement différents paramètres, il a été brisé à nouveau.

+1 pour la mise à jour.

OriginalL'auteur Pretzel
0

J'ai vu un problème similaire lors de l'utilisation de l'app.config. Essayez de lancer votre application à partir de l' .exe au lieu de partir de Visual Studio & voir si elle se comporte alors comme prévu.

J'ai essayé de courir à partir de la .exe -- pas de chance. Merci pour la suggestion, cependant.

OriginalL'auteur
0

Il est possible que dans votre fichier DLL, vous avez le modificateur d'accès (pour le Settings1.Les paramètres) Interne (Ami pour VB). Essayez de changer le Modificateur d'Accès Public et voir si cela permet à votre application de lecture/écriture des valeurs de dll config.

OriginalL'auteur
0

La réponse de Howard couvre la théorie.

Une façon rapide et sale de la résolution de ce est d'analyser le fichier de configuration xml manuellement.
```
    string configFile = Assembly.GetExecutingAssembly().Location + ".config";
    XDocument.Load(configFile).Root.Element("appSettings")....
```
OriginalL'auteur kasper
-1

L'erreur je pense que vous faites est que vous semblez faire referece à la DLL Paramètres via Settings1.Default.IPAddress alors que vous êtes tout simplement soi-disant pour ce faire Settings1.IPAddress.

La différence est que lorsque vous utilisez Settings1.Default.IPAddress les valeurs sont obtenus à partir des valeurs codées en dur imbeded dans le fichier d'assemblage (.dll ou .exe) comme Attribut [global::System.La Configuration.DefaultSettingValueAttribute(...)].

Tout Settings1.IPAddress est la valeur qui est modifiable dans le fichier .dll.config (fichier XML)**. donc, toutes les modifications apportées dans le fichier XML, il n'est pas reflétée dans codé en dur la valeur par défaut dans l'assemblée.

Pas ceci:
```
IP = IPAddress.Parse(Settings1.Default.IPAddress);
```
Mais essayez ceci:
```
*IP = IPAddress.Parse(Settings1.IPAddress);
```
Je ne suis pas sûr si vous avez réellement essayé cela, mais les Paramètres.Par défaut.someSetting est le seul moyen pour avoir accès à "someSetting' en utilisant le code généré par le fichier de Paramètres de la section dans les propriétés du Projet. Si vous essayez d'accéder aux Réglages.someSetting, vous obtiendrez une erreur de compilation (j'ai essayé car je n'ai jamais vu cela suggère avant).

OriginalL'auteur MRHIMAN

Vous devez vous connecter pour publier un commentaire.