Votre avis sur l'utilisation des app.config dans les dll

**kheironn** · 10/10/2013, 11h01

Bonjour,
Lors d'une discussion entre collègue une question à été posée.
.Net prévoit que l'on peut utiliser des settings (dans les propriétés du projet) pour des dll. Cela génère donc des sections (ApplicationSettings / UserSettings) dans un fichier app.config, que l'on doit ensuite intégrer dans un web.config, dans le cas d'une appli web.

L'avantage, on peut faire un Properties.Settings.etc. pour récupérer le paramètre.

Ma question : est-ce oui ou non une bonne pratique ?

**AsPrO** · 10/10/2013, 11h12

Ta question se porte sur l'utilisation général des settings dans un fichier de configuration (app.config, web.config) ou plutot l'opposition à utiliser les propriétés settings d'un projet VS directement les rentrer nous même dans la balise <appSettings> ?

**kheironn** · 10/10/2013, 11h52

Envoyé par AsPrO

Ta question se porte sur l'utilisation général des settings dans un fichier de configuration (app.config, web.config) ?

Oui.

Personnellement, je trouve qu'ajouter des clefs dans appSetting et de faire ConfigurationManager.etc est moins bien qu'utiliser les propriétés typées.

Donc ma question porte bien sur "Faut-il utiliser les settings dans une dll ou les laisser dans l'application et passer les valeurs en paramètre de méthode ?"

Un exemple simple, où je travaille, certains utilisent le web.config avec une ConnectionString (normal) et passent de couchent en couche cette chaine jusqu'à la DAL. Je trouve plus simple de configurer directement la DAL avec cette chaine.

Chaque dll a ses propres settings et agit indépendamment de la config des autres. Il faut juste reporter le contenu de l'app.config dans le web.config...

Est-ce plus clair ?

**meziantou** · 10/10/2013, 12h05

Il y a une troisième solution non évoquée, les ConfigurationSection

**kheironn** · 10/10/2013, 12h51

Peut-être, mais là on dérive sur des aspects techniques visant à voir comment faire.

Ma question n'est pas comment, mais "est-ce bien de le faire ?"

Pour simplifier à fond : est-ce qu'une dll doit embarquer sa propre configuration ou doit-elle dépendre d'autres éléments de l'application ?

**meziantou** · 10/10/2013, 15h10

Faut-il utiliser les settings dans une dll ou les laisser dans l'application et passer les valeurs en paramètre de méthode ?

Je ne vois pas ce qu'il y a de choquant à mettre les settings dans le fichier app.config et à utiliser directement les valeurs dans la DLL.
Le Framework .NET utilise beaucoup le fichier de configuration (il suffit de voir tout ce que l'on peut mettre dans un fichier app.config ou web.config) et ça n'a pas l'air de choquer les utilisateurs.

Tu peux aussi faire un système mixe: tu utilises ce que tu trouve dans le fichier de config et l'application peut overrider les valeurs. C'est par exemple ce que tu peux faire avec la classe SmtpClient. Par défaut ça récupère les valeurs dans le fichier de config, mais tu peux spécifier les valeurs que tu souhaites à partir de l'application.

**AsPrO** · 10/10/2013, 18h06

Quand tu parles de mettre les valeurs dans les .dll, tu veux dire hardcoder les paramètres dans des variables constantes ?
[EDIT] Après relecture, tu veux surement dire que chaque dll à son propre fichier de configuration.

**meziantou** · 10/10/2013, 18h16

C'est plutôt que chaque DLL contient du code pour lire les paramètres dans le fichier de configuration (qui lui est unique).

**Babyneedle** · 11/10/2013, 14h10

Toute cette discussion relève en fait de la stratégie de responsabilité de dépendances.

La stratégie la plus crédible (à mon humble avis) est l'injection de dépendances qui veut qu'un client d'un module injecte lui-même une dépendance.

Par exemple, prenons un site web utilisant une DLL maison qui envoie des emails, personnellement, je vais injecter l'addresse du serveur smtp.

Comme les fichiers de configuration sont transformables automatiquement par environnement, j'ai tout à gagner à pouvoir dire à l'outil que je suis sur un serveur de test par exemple.

On peut injecter à la main par le constructeur ou bien utiliser des librairies à cet effet telles que Ninject en assumant que l'interdépendance des couches soit respectée.

Je te propose une lecture afin d'aller plus en détails: Dependency injection in .net

**kheironn** · 11/10/2013, 16h35

@Babyneedle

Si j'ai bien compris ton propos, tu es pour que seule la couche applicative aie des paramètres de configuration et que lorsqu'elle appelle une instance/méthode issue d'une dll, elle lui fourni en paramètre ce qu'elle a remonté de sa configuration.

Ce principe est contraire à ce que je fais, mais la question est de savoir si ce que je fais est une bonne ou une mauvaise pratique.

J'espère que d'autres continueront à donner leur avis.

**kheironn** · 16/10/2013, 19h40

En quoi est-ce moins bien d'utiliser les app.config des dll que de passer toute la configuration dans le web/exe.config et de transmettre le paramétrage par paramètre de méthode ou constructeur? L'indépendance des couches voudrait plutôt le contraire.

**morgand** · 16/10/2013, 22h52

Bonsoir,

Si j'ai bien compris, et pour l'expliquer je vais reprendre ton exemple, tu préfères écrire en dur une ConnectionString dans une class plutôt que de l'écrire dans un fichier Web/App .config.

Et tu te demandes si cela est ou pas une bonne pratique. Je vais reformuler ta question par la suivante :

Es ce que paramétrer une application (Riche ou Légère) via le fichier app.config est une bonne pratique ?

Personnellement, je dis que "Oui". Dans un premier temps je vais répondre à ton exemple :

A un niveau Architecture ta DAL est présente pour te donner accès à une abstraction d'un source de donnée spécifique (C'est un peu compliqué dit comme ça).

Data Access Layer, est une couche d'accès aux données que se soit SGBD, XML, Binaire, Network etc.
La DAL te donne une façon spécifique de lire de la donnée venant d'une source

Mais es ce que cette source est figée dans le marbre, aujourd'hui ta source de donnée se trouve sur un MySQL Server sous la data base MyDataBase.
Et finalement ton projet prend de la valeur aux yeux des décideurs, mais le système de base de données ne leurs convient pas pour des raisons de performances et ils te payent u SQL Server 2012 qui roxxe du poney.
As tu envie de reprendre ton code, changer ta ConnectionString écrite en dure dans ta DAL et finalement recompiler (ta DAL) pour redéployer ton site ?

Et bien non, tu changes ta ConnectionString dans ton fichier de configuration d'application.

Le principe de l'appconfig te permet de rendre tes exécutions paramétrables et donc d'avoir un couplage faible entre la configuration et ton code, dit autrement ton code peut s'adapter de lui même suivant une configuration.

Je vais prendre un exemple plus bateau mais très parlent, es ce que tu crois que l'informatique en serait là aujourd'hui si à chaque fois que tu devais faire une ligne de commande il aurait fallu recompiler la ligne de commande avec tes paramètres :

Code :

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

1
2
Compilation dir with parameters c:\
Exec dir

Alors dit comme ça c'est un peu abusé, il est plus facile de configurer une application dans un fichier de configuration que de le compiler ou de passer des arguments dans une ligne de commande.

Bon maintenant que j'ai bien défendu le truc, on pourrait dire que ça a un coup de lire un fichier XML au démarrage. Bon déjà quand tu démarres ton site internet d'entreprise je ne pense pas que ton site redémarre toutes les 10 secondes. Donc la 1/2 seconde permettant d'aller configurer lire la data dans le fichier et de la descendre à la DAL (je pense qu'on est même en dessous de la 1/2 seconde) est négligeable.

Le fichier de configuration te permet d'aller beaucoup plus loin que tout ça, je te conseille d'aller voir sur MSDN toutes les possibilités qu'apporte le fichier de configuration d'application. Ensuite tu le mets en parallèle avec la possibilité que tu as d'abstraire ton application et de faire un couplage faible entre les modules de ton application.

Donc pour résumer si quelqu'un n'a pas envie de tout lire, Oui l'utilisation du fichier de configuration est une très bonne pratique, comme tout outil il faut savoir l'utiliser, comprendre les avantages, les inconvénients, les possibilités et savoir les transposer.

Ne pas l'utiliser est pour moi une mauvaise pratique.

**moldavi** · 16/10/2013, 23h47

Bonjour.

Faut-il coder en dur "connectionString", ou faut-il mettre "connectionString" dans un fichier de config.

Je pense qu'il n'y a pas de règle, et c'est au développeur de prendre sa décision.

Personnellement, je code tout en dur, et quand un paramètre doit être configurable, je le sort du code et je le mets dans un fichier de config.

D'autres personnes diront que c'est bien de le mettre tout de suite dans un fichier de config, histoire d'anticiper.

C'est au choix du développeur. De toute façon l'une ou l'autre solution n'empêche pas le programme de fonctionner. Et si la "connectionString" ne change jamais durant la vie du logiciel, cela n'aura aucun impact.

Et puis bon la "connectionString" avec le mot de passe de la base de données dans un fichier non crypté...

**morgand** · 17/10/2013, 00h13

Envoyé par moldavi

Bonjour.

Faut-il coder en dur "connectionString", ou faut-il mettre "connectionString" dans un fichier de config.

Je pense qu'il n'y a pas de règle, et c'est au développeur de prendre sa décision.

Je ne suis pas d'accord avec toi, c'est en rapport avec les besoins. Si ton client explique qu'il doit pouvoir déployer son application sur différent site ou sur différente URL avec des bases de données différentes alors le fichier config se révèle plus qu'utile.

Dans mon explication je ne dis pas que la ConnectionString doit obligatoirement être dans le fichier de config, je dis qu'à partir du moment ou l'application doit être paramétrable, intégrable, etc. alors c'est une bonne pratique et ne pas l'utiliser serait la mauvaise pratique.

Donc pour résumer si quelqu'un n'a pas envie de tout lire, Oui l'utilisation du fichier de configuration est une très bonne pratique, comme tout outil il faut savoir l'utiliser, comprendre les avantages, les inconvénients, les possibilités et savoir les transposer.

Et se serait ne pas l'utiliser quand on en a besoin qui serait une mauvaise pratique.

**kheironn** · 17/10/2013, 16h19

@morgand
Tu ne m'as pas compris.

Tu as une archi avec 3 dll/projet, dont l'un est, par exemple, une web app.
Tu as donc, dans les propriétés des tes 3 projets, une section settings qui se retrouve dans un app.config (web.config pour la web app).
Ce que je fais, dans mon projet DAL, j'utilise des settings qui génère ça :

Code :

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

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
    </configSections>
    <connectionStrings>
        <add name="ClassLibrary3.Properties.Settings.DllCnxStr" connectionString="Data Source=XXXXXXX;User ID=toto;Password=fjks;Unicode=True" providerName="System.Data.OracleClient" />
    </connectionStrings>
</configuration>

avec un exemple en code, c'est peut-être plus clair.

dans un autre projet j'ai ça

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
        </sectionGroup>
        <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
        </sectionGroup>
    </configSections>
    <applicationSettings>
        <ClassLibrary1.Properties.Settings>
            <setting name="DllFieldOne" serializeAs="String">
                <value>Tutu</value>
            </setting>
        </ClassLibrary1.Properties.Settings>
    </applicationSettings>
    <userSettings>
        <ClassLibrary1.Properties.Settings>
            <setting name="DllFieldTwo" serializeAs="String">
                <value>Tata</value>
            </setting>
        </ClassLibrary1.Properties.Settings>
    </userSettings>
  <appSettings>
    <add key="DllKeyOne" value="My Key !"/>
    <add key="DllKeyTwo" value="My Second Key !"/>
  </appSettings>
</configuration>

et enfin dans mon web.config ça

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
<?xml version="1.0"?>
 
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
 
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="WebApplication1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <connectionStrings>
    <add name="ApplicationServices"
         connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true"
         providerName="System.Data.SqlClient" />
  </connectionStrings>
 
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
 
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login.aspx" timeout="2880" />
    </authentication>
 
    <membership>
      <providers>
        <clear/>
        <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices"
             enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
             maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
             applicationName="/" />
      </providers>
    </membership>
 
    <profile>
      <providers>
        <clear/>
        <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="ApplicationServices" applicationName="/"/>
      </providers>
    </profile>
 
    <roleManager enabled="false">
      <providers>
        <clear/>
        <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="ApplicationServices" applicationName="/" />
        <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
      </providers>
    </roleManager>
 
  </system.web>
 
  <system.webServer>
     <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
  <applicationSettings>
    <WebApplication1.Properties.Settings>
      <setting name="WebFieldOne" serializeAs="String">
        <value>NafNaf</value>
      </setting>
      <setting name="WebFieldTwo" serializeAs="String">
        <value>NifNif</value>
      </setting>
    </WebApplication1.Properties.Settings>
  </applicationSettings>
</configuration>

au final, ma configuration est répartie dans plusieurs app/web.config.
Je dois fusionner les diffférents app.config dans mon web.config comme ça

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
<?xml version="1.0"?>
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="WebApplication1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
      <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
    <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
      <section name="ClassLibrary2.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login.aspx" timeout="2880" />
    </authentication>
    <membership>
      <providers>
        <clear />
        <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="/" />
      </providers>
    </membership>
    <profile>
      <providers>
        <clear />
        <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="ApplicationServices" applicationName="/" />
      </providers>
    </profile>
    <roleManager enabled="false">
      <providers>
        <clear />
        <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="ApplicationServices" applicationName="/" />
        <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
      </providers>
    </roleManager>
  </system.web>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
  <applicationSettings>
    <WebApplication1.Properties.Settings>
      <setting name="WebFieldOne" serializeAs="String">
        <value>NafNaf</value>
      </setting>
      <setting name="WebFieldTwo" serializeAs="String">
        <value>NifNif</value>
      </setting>
    </WebApplication1.Properties.Settings>
    <ClassLibrary1.Properties.Settings>
      <setting name="DllFieldOne" serializeAs="String">
        <value>Tutu</value>
      </setting>
    </ClassLibrary1.Properties.Settings>
  </applicationSettings>
  <appSettings>
    <add key="DllKeyOne" value="My Key !" />
    <add key="DllKeyTwo" value="My Second Key !" />
  </appSettings>
  <connectionStrings>
    <add name="ApplicationServices" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" />
    <add name="ClassLibrary3.Properties.Settings.DllCnxStr" connectionString="Data Source=XXXXXXX;User ID=toto;Password=fjks;Unicode=True" providerName="System.Data.OracleClient" />
  </connectionStrings>
  <userSettings>
    <ClassLibrary1.Properties.Settings>
      <setting name="DllFieldTwo" serializeAs="String">
        <value>Tata</value>
      </setting>
    </ClassLibrary1.Properties.Settings>
    <ClassLibrary2.Properties.Settings>
      <setting name="WebDllFieldOne" serializeAs="String">
        <value>NufNuf</value>
      </setting>
    </ClassLibrary2.Properties.Settings>
  </userSettings>
</configuration>

Ma question concerne l'utilisation des configuration des dll/projet de type librairie, par exemple.

Certains m'ont dit de ne pas faire ça, de faire des appSetting et de passer leur valeur depuis le web.config, via paramètre ou constructeur, jusqu'à la dll qui en a besoin.

Ma question est donc pour ne pas utiliser la configuration inhérante à chaque projet/dll ?

**moldavi** · 17/10/2013, 21h41

Re.

Envoyé par morgand

Si ton client explique qu'il doit pouvoir déployer son application sur différent site ou sur différente URL avec des bases de données différentes alors le fichier config se révèle plus qu'utile.

Je suis bien d'accord. Le client le demande, donc on le fait.

Si le client ne le demande pas, on est pas obligé de le faire, c'est au choix.

Envoyé par kheironn

Ma question est donc pour(quoi) ne pas utiliser la configuration inhérante à chaque projet/dll ?

Ceux qui te conseillent cela, préfèrent peut-être ne consulter qu'un seul fichier, plutôt qu'une multitude de fichier de config, lors d'une maintenance ?

**morgand** · 17/10/2013, 23h00

Effectivement je n'avais pas compris ta question.

Maintenant, je pense qu'il n'y a pas de solution toute faite à ta question. Tout va dépendre du projet sur lequel tu travailles. Dans le cas présent effectivement je ne ferai pas de fichier de configuration pour chaque DLL. App/Web config définit pour un environnement d'exécution des paramètres à passer pour le bon fonctionnement de l'exécution.

Pour moi, tu as deux cas:

Le projet demande une configuration spécifique un environnement d'exécution
Le projet demande une configuration spécifique à un environnement d'exéution mais aussi à d'autre élément customizable, exemple un envirronement par session client

Pour la seconde, je pense que ça doit être rare en Web, en revanche pour tout ce qui est d'application riche (WinForm) c'est beaucoup plus fréquent

En gros tu as l'environnement d'exécution et tu as environnement client, pour ce qui est de l'exécution tu vas retrouver tout ce qui va correspondre à des informations techniques, point d'accès réseaux, URL particulière pour retrouver des DLL ou autres. Dans le client tu peux retrouver une connexion à une base de données clientes, URL pour pointé sur des fichiers spécifiques.

Je sais pas si j'ai été clair. Si non, je pourrai donner un exemple plus concret. Au vue de ton exemple je dirai que je ferai un seul fichier de configuration Web.Config ce qui me permettrai de garder les couches bases indépendantes au niveau initialization. En gros que la source des paramètres viennent d'un fichier XML, d'une base de données, d'un code en dur via un autre programme tu es tranquille ton code fonctionnera toujours.

**youtpout978** · 17/10/2013, 23h32

Je travail sur une appli web SharePoint et on a tout un paquet de config pour différente dll/features qu'on utilise, ils sont dans un répertoire config à la racine du site et dans le web.config on référence chacun de ses fichiers config, ça peut être une solution pour toi.
Sur mon site web perso j'ai un composant de forum qui lui aussi est scindé en plusieurs fichier config pour différent module et chaque fichier config est référencé dedans.
Juste à faire ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
<?xml version="1.0" encoding="utf-8"?>
<configuration>
 
	<configSections>
		<section name="rewriter" type="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler, Intelligencia.UrlRewriter" requirePermission="false"/>
	</configSections> 	
 
	<connectionStrings configSource="db.config"/>
	<appSettings configSource="app.config"/>
	<rewriter configSource="URLRewriter.config" />
 
	<system.net>
		<mailSettings>
			<smtp configSource="mail.config"/>
		</mailSettings>
	</system.net>
 
	<system.web>

Pour la connectionstring je la met toujours dans le web.config, toute façon dès que tu te connectes à une bdd depuis visual studio la connection string est sauvegardé automatiquement dans le web.config, et si tu crée un projet web il te crée plusieurs web.config (un pour le debug, pour le release ...) ce qui permet justement d'avoir une connectionstring pour l'environnement de dev une autre pour la prod ...
Et c'est pas forcément plus malin de mettre la connectionstring dans l'appli parce que tu peux facilement lire le code d'une appli .net et il est possible de crypter le web.config si les infos sont trop sensible.

**kheironn** · 24/10/2013, 14h24

Merci pour vos différents avis.
Comme toujours, la réponse revient à "ça dépend de ton architecture"...

Votre avis sur l'utilisation des app.config dans les dll

C#

Discussions similaires

Partager

Partager