Discussion :

[cortex024]

Bonjour,

j'ai une application .net que je dois déployer avec des paramètres différents (urls et certaines valeurs à changer suivant le déploiement).

en temps normal, j'utilise un fichier de config pour stocker ces valeurs et les récupérer via

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ConfigurationManager.AppSettings("myresource")

Cependant, cette récupération se fait à la volée et ce fichier de config doit se trouver dans le répertoire de l'application.


Pour mon cas problématique, je ne peux/sais pas placer des fichiers dans le répertoire de mon application, il s'agit d'une unique dll en sortie.
j'aimerais donc un espère de fichier de config, mais qui à la compilation pour le déploiement, remplace directement les valeurs à partir du fichier de config.
En sortie, ces paramètres seraient donc figés comme si il n'y avait pas de paramètres relié à un fichier (pas de possibilité d'avoir un fichier de config à côté qu'on peut modifier à chaud), mais au moins je garde l'avantage d'avoir tout qui est paramétré dans un seul fichier côté développement.

j'ai essayé de chipoter avec les "actions de génération" du fichier de config mais je ne trouve rien de clair la dessus et ca ne fonctionne pas.

Comment faire?

[Guulh]

Une classe statique avec des constantes ne te suffirait-elle pas ?

[cortex024]

Une classe statique avec des constantes ne te suffirait-elle pas ?

effectivement, de manière pratique ca fonctionnerait et me permettrait d'isoler dans un fichier séparé mes paramètres.

mais théoriquement, ca me gênait de devoir contourner le problème avec un trick de ce genre là. j'avais pensé à mettre ma classe en partial et définir mes paramètres dans un autre fichier de la même classe.

merci tout de même pour ta réponse

Si quelqu'un a une solution plus propre avec un type de paramétrage ou une intégration à la compilation de paramètres tel que décris ci-dessus ca serait pas plus mal

[tomlev]

Une classe statique avec des constantes ne te suffirait-elle pas ?

Non, pas des constantes. Des champs statiques en lecture seule plutôt.

Quand tu compiles un projet qui référence un assembly X, les constantes définies dans X sont remplacées par leur valeur quand ton projet est compilé. Si les valeurs des constantes de X changent par la suite, ton code n'en tiendra pas compte à moins d'être recompilé. Donc pour des valeurs qui sont susceptibles de changer, il faut toujours utiliser des champs et non des constantes. Les constantes sont à réserver aux valeurs qui ne changeront jamais (par exemple constantes physiques ou mathématiques)

[Guulh]

Non, pas des constantes. Des champs statiques en lecture seule plutôt.

Quand tu compiles un projet qui référence un assembly X, les constantes définies dans X sont remplacées par leur valeur quand ton projet est compilé.

Vi, vi, je connais la différence entre static readonly et const Mais si ces valeurs ne servent qu'à la dll elle-même (si la classe les contenant n'est pas publique, en fait), ça revient au même, puisqu'elles ne sont pas référencées de l'extérieur.

Pour en revenir au problème initial : avec les settings projet (ceux que l'on voit dans l'onglet "settings" du projet), la valeur par défaut des paramètres est stockées directement dans le code, sous forme d'attributs, pour chacune des propriétés de la classe "Settings" générée. Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
        [global::System.Configuration.ApplicationScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute("La Valeur")]
        public string UnParamètre {
            get {
                return ((string)(this["UnParamètre"]));
            }
        }

Il me semble qu'en l'absence de fichier de conf, c'est cette valeur par défaut qui est prise. Tu devrais essayer d'ajouter de tels settings à ta dll, de virer les fichiers de conf du répertoire de sortie, et vérifier que tu retrouves bien la valeur spécifiée dans l'attribut. Au pire, un coup de réflexion permet de retrouver la valeur manuellement (mais bon ça complique les choses, alors que ces settings sont faits pour n'avoir rien à coder)

[Bluedeep]

Quand tu compiles un projet qui référence un assembly X, les constantes définies dans X sont remplacées par leur valeur quand ton projet est compilé. Si les valeurs des constantes de X changent par la suite, ton code n'en tiendra pas compte à moins d'être recompilé. Donc pour des valeurs qui sont susceptibles de changer, il faut toujours utiliser des champs et non des constantes. Les constantes sont à réserver aux valeurs qui ne changeront jamais (par exemple constantes physiques ou mathématiques)

Beaucoup de dev. ont une facheuse tendance à oublier cette nuance (en plus de ceux, nombreux, qui l'ignorent). Une bonne chose de le souligner