Je veux utiliser un seul app.config par 3 projets différents.
Comment accéder aux configurations?
ConfigurationManager.AppSettings["config1"]
Le fichier de configuration commun
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section
name="appSettings"
type="System.Configuration.AppSettingsSection, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
/>
</configSections>
<appSettings>
<add key="key1" value="value1"/>
</appSettings>
</configuration>
Pour accéder au fichier de configuration mappé
ConfigurationFileMap fileMap = new ConfigurationFileMap(file); //Path to your config file
Configuration configuration = ConfigurationManager.OpenMappedMachineConfiguration(fileMap);
string value = configuration.AppSettings.Settings["key1"].Value;
Disons que vous avez cette structure de dossiers:
Faites ceci:
Pour chaque projet dans l'Explorateur de solutions:
Modifié pour ajouter:
Vous déclarez correctement que la méthode ci-dessus n'a partagé le fichier que lors de la génération. Pour utiliser un fichier partagé au moment de l'exécution, voir réponses à cette question .
Voici la boîte de dialogue "Ajouter un élément existant" dans VS 2008:
Cliquez sur le petit indicateur déroulant du bouton "Ajouter" et choisissez "Ajouter comme lien" dans le menu contextuel.
Marc
J'ai trouvé le bouton et ouvert le fichier app.config en tant que lien.Cependant, lorsque la construction a créé de nouveau un fichier de configuration distinct pour chaque projet, et donc, lors du déploiement du projet 3, j'ai 3 fichiers de configuration. Ce que je voulais faire, c'est garder un seul fichier pour tous les projets dans une certaine solution. Puis-je faire cela?
Oui - vous pouvez le faire, mais devriez-vous le faire?
L'hypothèse de base dans une application .NET est qu'une application = un fichier de configuration. Par défaut, et avec une méthode simple, vous ne pouvez pas partager des fichiers de configuration entre des applications.
Si vous créez vos propres sections de configuration personnalisées, vous pouvez les "externaliser" vers des fichiers externes, qui peuvent être partagés. Imaginez que vous créez votre propre section de configuration personnalisée appelée "MyConfiguration", alors votre app.config ressemblerait à quelque chose comme ça:
<configuration>
<configSections>
<section name="MyConfiguration"
type="MyConfigurationSection, MyConfigurationAssembly" />
</configSections>
<MyConfiguration>
<nestedElement>
<dateTimeValue>10/16/2006</dateTimeValue>
<integerValue>1</integerValue>
</nestedElement>
</MyConfiguration>
</configuration>
Vous pouvez avoir votre section "MyConfiguration" dans son propre fichier et la référencer depuis la configuration de votre application:
<configuration>
<configSections>
<section name="MyConfiguration"
type="MyConfigurationSection, MyConfigurationAssembly" />
</configSections>
<MyConfiguration configSource="MyConfiguration.config" />
</configuration>
et votre "MyConfiguration.config" contiendrait alors:
<MyConfiguration>
<nestedElement>
<dateTimeValue>10/16/2006</dateTimeValue>
<integerValue>1</integerValue>
</nestedElement>
</MyConfiguration>
En faisant cela, vous pouvez "externaliser" et partager ainsi au moins la majeure partie de vos paramètres de configuration - à condition qu'ils soient dans vos propres sections de configuration personnalisées.
Pour plus d'informations et une excellente introduction à .NET 2.0 et aux mystères de configuration, consultez la série en trois parties de Jon Rista sur la configuration .NET 2.0 sur CodeProject.
Hautement recommandé, bien écrit et extrêmement utile!
Marc
Une option de conception consiste à éviter d'accéder à app.config directement à partir de vos projets de bibliothèque de classes, évitant ainsi la dépendance externe supplémentaire.
Au lieu de cela, seul votre projet exécutable connaît le fichier de configuration et il peut explicitement transmettre les informations de configuration appropriées aux bibliothèques lorsqu'il crée des objets à partir d'eux ou les initialise.
Je comprends que c'est une vieille question, mais il existe un moyen beaucoup plus facile d'y parvenir. Si vous utilisez Visual Studio 2008 ou supérieur, il existe un type de projet appelé "Projet partagé".
Un projet partagé peut avoir à peu près tout ce qu'un autre type de projet peut contenir. Ce n'est pas seulement pour C # mais pour tous les langages pris en charge par VS2015. Lorsqu'un élément est inclus dans le projet partagé, il est disponible pour d'autres projets après que vous y avez ajouté une référence (voir ci-dessous).
La principale différence avec les classes d'un projet partagé par rapport à une bibliothèque partagée est que lorsque vous compilez le programme, tout ce qui se trouve dans le projet partagé sera compilé directement dans votre projet et non dans un fichier distinct (.dll, .exe). Considérez-le comme tout ce qui se trouve dans le projet partagé est inséré dans les autres projets. Voici un petit tutoriel sur la configuration et l'utilisation de celui-ci:
Créez le nouveau projet partagé en sélectionnant Fichier-> Nouveau-> Projet ou cliquez avec le bouton droit sur la solution dans l'explorateur de solutions et sélectionnez Ajouter-> Nouveau projet . Lorsque la boîte de dialogue apparaît, sélectionnez "Projet partagé", donnez au projet un nom TestShared dans cet exemple.
Une fois le nouveau projet ajouté, vous pouvez ajouter tout ce dont vous avez besoin pour être disponible pour d'autres projets. Dans ce cas, nous ajouterons app.config. Faites un clic droit sur le projet partagé et sélectionnez Ajouter-> Nouvel élément . Sélectionnez Visual C # -> Données-> Fichier XML en le nommant évidemment à app.config.
Enfin, ajoutez une référence au projet partagé en cliquant avec le bouton droit sur le projet avec lequel vous devez partager le projet et sélectionnez Ajouter-> Référence. Dans la boîte de dialogue Gestionnaire de références, sélectionnez votre projet partagé, il sera répertorié sous l'élément "Projets partagés" à gauche.
Maintenant, tout ce qui est dans le projet partagé est disponible dans l'autre projet, il n'est plus nécessaire de faire des importations ou quelque chose comme ça. Cela fonctionne simplement. Ce modèle est assez pratique lorsque vous développez un programme et devez avoir plusieurs interfaces graphiques différentes (Windows, iOS, Android etc). Par exemple, vous pouvez avoir un projet partagé pour la fonctionnalité "Core" puis avoir un projet GUI distinct pour chacun des différents systèmes d'exploitation que vous souhaitez prendre en charge dans votre programme.
Je me rends compte que c'est une question plus ancienne, mais comme cela est apparu dans Google, j'ai pensé que je répondrais à cela alors que d'autres recherchent la même chose qu'ils savent sur cette fonctionnalité VS très puissante.
System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config = ConfigurationManager.OpenExeConfiguration(Path.Combine(@"D:\", "config.exe"));
foreach (string key in config.AppSettings.Settings.AllKeys)
{
string value = config.AppSettings.Settings[key].Value;
ConfigurationManager.AppSettings.Set(key, value);
}