Transformation App.Config pour les projets qui ne sont pas des projets Web dans Visual Studio 2010 ?

Question

Pour Visual Studio 2010 Web-based application nous avons Config Transformation fonctionnalités par lequel nous pouvons maintenir plusieurs fichiers de configuration pour les différents environnements. Mais la même fonctionnalité n'est pas disponible pour les fichiers App.Config pour les services Windows/WinForms ou l'application console.

Il existe une solution de contournement, comme suggéré ici : Appliquer la magie XDT à App.Config .

Cependant, ce n'est pas simple et cela nécessite un certain nombre d'étapes. Existe-t-il un moyen plus simple d'obtenir la même chose pour les fichiers app.config ?

Answer 1

Mise à jour

Cette réponse est quelque peu dépassée. Je vais la laisser pour l'histoire et les personnes qui préfèrent ne pas utiliser de modules complémentaires pour une raison quelconque. Veuillez vous référer à Réponse de Scott à moins que vous ne sachiez ce que vous faites.

---

J'ai essayé plusieurs solutions, et voici la plus simple que j'ai trouvée.
Dan a souligné dans les commentaires que le billet original appartient à Oleg Sych - Merci, Oleg !

Voici les instructions :

1. Ajoutez au projet un fichier XML pour chaque configuration.

En général, vous aurez Debug et Release donc nommez vos fichiers App.Debug.config et App.Release.config . Dans mon projet, j'ai créé une configuration pour chaque type d'environnement, vous pouvez donc l'expérimenter.

2. Déchargez le projet et ouvrez le fichier .csproj pour le modifier.

Visual Studio vous permet de modifier .csproj directement dans l'éditeur - vous devez juste décharger le projet avant. Ensuite, cliquez avec le bouton droit de la souris sur le projet et sélectionnez Modifier le fichier <Nom du projet>.csproj .

3. Lier les fichiers App.*.config à l'App.config principal

Trouvez la section du fichier du projet qui contient tous les App.config et App.*.config références. Vous remarquerez que leurs actions de construction sont réglées sur None :

<None Include="App.config" />
<None Include="App.Debug.config" />
<None Include="App.Release.config" />

Tout d'abord, définissez une action de construction pour chacun d'entre eux pour Content .
Ensuite, faites en sorte que tous les Configuration spécifique fichiers personne à charge sur le principal App.config afin que Visual Studio les regroupe comme il le fait pour les fichiers de conception et de codebehind.

Remplacez le XML ci-dessus par celui ci-dessous :

<Content Include="App.config" />
<Content Include="App.Debug.config" >
  <DependentUpon>App.config</DependentUpon>
</Content>
<Content Include="App.Release.config" >
  <DependentUpon>App.config</DependentUpon>
</Content>

4. Activer la magie des transformations

En fin de dossier après

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

et avant la finale

</Project>

insérer le XML suivant :

  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
  <Target Name="AfterCompile" Condition="exists('app.$(Configuration).config')">
    <!-- Generate transformed app config in the intermediate directory -->
    <TransformXml Source="app.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="app.$(Configuration).config" />
    <!-- Force build process to use the transformed configuration file from now on. -->
    <ItemGroup>
      <AppConfigWithTargetPath Remove="app.config" />
      <AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
        <TargetPath>$(TargetFileName).config</TargetPath>
      </AppConfigWithTargetPath>
    </ItemGroup>
  </Target>

Maintenant vous pouvez recharger le projet, le construire et en profiter. App.config transformations !

Answer 2

Cela fonctionne maintenant avec le Visual Studio AddIn traité dans cet article : SlowCheetah - La syntaxe de transformation de Web.config est maintenant généralisée pour tout fichier de configuration XML .

Answer 3

Une autre solution que j'ai trouvée est de NE PAS utiliser les transformations mais d'avoir un fichier de configuration séparé, par exemple app.Release.config. Ensuite, ajoutez cette ligne à votre fichier csproj.

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
    <AppConfig>App.Release.config</AppConfig>
  </PropertyGroup>

Cela va non seulement générer le bon fichier myprogram.exe.config, mais si vous utilisez Setup and Deployment Project dans Visual Studio pour générer des MSI, cela forcera le projet de déploiement à utiliser le bon fichier de configuration lors de l'emballage.

Answer 4

D'après mon expérience, les éléments que je dois rendre spécifiques à l'environnement sont des choses comme les chaînes de connexion, les appsettings et souvent les paramètres smpt. Le système de configuration permet de spécifier ces choses dans des fichiers séparés. Vous pouvez donc utiliser ceci dans votre app.config/web.config :

 <appSettings configSource="appsettings.config" />
 <connectionStrings configSource="connection.config" />
 <system.net>
    <mailSettings>
       <smtp configSource="smtp.config"/>
    </mailSettings>
 </system.net>

Ce que je fais généralement, c'est de placer ces sections spécifiques à la configuration dans des fichiers séparés, dans un sous-dossier appelé ConfigFiles (soit dans la racine de la solution, soit au niveau du projet, cela dépend). Je définis un fichier par configuration, par exemple smtp.config.Debug et smtp.config.Release.

Vous pouvez alors définir un événement de pré-construction comme suit :

copy $(ProjectDir)ConfigFiles\smtp.config.$(ConfigurationName) $(TargetDir)smtp.config

Dans le cadre d'un développement en équipe, vous pouvez affiner ce principe en incluant le %COMPUTERNAME% et/ou le %USERNAME% dans la convention.

Bien entendu, cela implique que les fichiers cibles (x.config) ne doivent PAS être placés dans le contrôle de la source (puisqu'ils sont générés). Vous devez néanmoins les ajouter au fichier de projet et définir leur propriété de type de sortie sur "copy always" ou "copy if newer".

Simple, extensible, et il fonctionne pour tous les types de projets Visual Studio (console, winforms, wpf, web).

Answer 5

Vous pouvez utiliser un fichier de configuration distinct par configuration, par exemple app.Debug.config, app.Release.config, puis utiliser la variable de configuration dans votre fichier de projet :

<PropertyGroup>
    <AppConfig>App.$(Configuration).config</AppConfig>
</PropertyGroup>

Ceci créera alors le fichier ProjectName.exe.config correct selon la configuration dans laquelle vous construisez.