Vous pouvez essayer l'approche suivante:

1. cliquez-Droit sur le projet dans l'Explorateur de solutions et sélectionnez Décharger le Projet.
2. , Le projet sera déchargé. Cliquez à nouveau avec le bouton droit sur le projet et sélectionnez Edit .csproj .
3. Vous pouvez maintenant modifier le fichier de projet dans Visual Studio.
4. Localisez l'endroit dans *.fichier csproj où votre fichier de configuration de l'application est inclus. Il ressemblera à:

    <ItemGroup>
        <None Include="App.config"/>
    </ItemGroup>

1. remplacez ceci lignes avec ce qui suit:

    <ItemGroup Condition=" '$(Configuration)' == 'Debug' ">
        <None Include="App.Debug.config"/>
    </ItemGroup>

    <ItemGroup Condition=" '$(Configuration)' == 'Release' ">
        <None Include="App.Release.config"/>
    </ItemGroup>

Je n'ai pas essayé cette approche pour les fichiers app.config, mais cela a bien fonctionné avec d'autres éléments de projets Visual Studio. Vous pouvez personnaliser le processus de construction de presque n'importe quelle façon que vous le souhaitez. De toute façon, laissez-moi savoir la suite.

Vous devriez considérer ConfigGen . Il a été développé à cet effet. Il produit un fichier de configuration pour chaque machine de déploiement, basé sur un fichier de modèle et un fichier de paramètres. Je sais que cela ne répond pas spécifiquement à votre question, mais cela pourrait bien répondre à votre problème.

Donc, plutôt que de déboguer, de publier, etc., vous pourriez avoir Test, UAT, Production, etc. Vous pouvez également avoir des paramètres différents pour chaque machine de développement, de sorte que vous pouvez générer une configuration spécifique à votre machine de développement et changez-le sans affecter le déploiement de quelqu'un d'autre.

Un exemple d'utilisation pourrait être...

<Target Name="BeforeBuild">
    <Exec Command="C:\Tools\cfg -s $(ProjectDir)App.Config.Settings.xls -t       
        $(ProjectDir)App.config.template.xml -o $(SolutionDir)ConfigGen" />

    <Exec Command="C:\Tools\cfg -s $(ProjectDir)App.Config.Settings.xls -t
        $(ProjectDir)App.config.template.xml -l -n $(ProjectDir)App.config" />
</Target>

Si vous placez cela dans votre .fichier csproj, et vous avez les fichiers suivants...

$(ProjectDir)App.Config.Settings.xls

MachineName        ConfigFilePath   SQLServer        

default             App.config      DEVSQL005
Test                App.config      TESTSQL005
UAT                 App.config      UATSQL005
Production          App.config      PRODSQL005
YourLocalMachine    App.config      ./SQLEXPRESS


$(ProjectDir)App.config.template.xml 

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
   <configuration>
   <appSettings>
       <add key="ConnectionString" value="Data Source=[%SQLServer%]; 
           Database=DatabaseName; Trusted_Connection=True"/>
   </appSettings>
</configuration>

... ensuite, ce sera le résultat...

A partir de la première commande, un fichier de configuration généré pour chaque environnement spécifié dans le fichier xls, placé dans le répertoire de sortie $ (SolutionDir)ConfigGen

.../solutiondir/ConfigGen/Production/App.config

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
   <configuration>
   <appSettings>
       <add key="ConnectionString" value="Data Source=PRODSQL005; 
           Database=DatabaseName; Trusted_Connection=True"/>
   </appSettings>
</configuration>

À partir de la deuxième commande, l'application locale.config utilisé sur votre dev la machine sera remplacée par la configuration générée spécifiée par le commutateur local (-l) et le commutateur filename (-n).

En utilisant la même approche que Romeo, Je l'ai adapté à Visual Studio 2010:

 <None Condition=" '$(Configuration)' == 'Debug' " Include="appDebug\App.config" />

 <None Condition=" '$(Configuration)' == 'Release' " Include="appRelease\App.config" />

Ici, vous devez garder les deux App.fichiers de configuration dans différents répertoires (appDebug et applelease). Je l'ai testé et cela fonctionne très bien!

J'utilise XmlPreprocess tool pour la manipulation des fichiers de configuration. Il utilise un fichier de mappage pour plusieurs environnements (ou plusieurs cibles de construction dans votre cas). Vous pouvez modifier le fichier de mappage par Excel. Il est très facile à utiliser.

SlowCheetah et FastKoala de la galerie VisualStudio semblent être de très bons outils pour résoudre ce problème.

Cependant, si vous voulez éviter les addins ou utiliser les principes qu'ils implémentent plus largement tout au long de vos processus de construction/intégration, l'ajout de ceci à vos fichiers MSBuild *proj est un raccourci.

Note: c'est plus ou moins une reprise du numéro 2 de la réponse de @oleksii.

Cela fonctionne pour .exe et .projets dll:

  <Target Name="TransformOnBuild" BeforeTargets="PrepareForBuild">
    <TransformXml Source="App_Config\app.Base.config" Transform="App_Config\app.$(Configuration).config" Destination="app.config" />
  </Target>

Cela fonctionne pour les projets web:

  <Target Name="TransformOnBuild" BeforeTargets="PrepareForBuild">
    <TransformXml Source="App_Config\Web.Base.config" Transform="App_Config\Web.$(Configuration).config" Destination="Web.config" />
  </Target>

Notez que cette étape se produit avant même le début de la construction proprement dite. La transformation du fichier de configuration se fait dans le dossier du projet. Alors que le web transformé.config est disponible lorsque vous déboguez (un inconvénient de SlowCheetah).

Rappelez-vous que si vous créez le dossier App_Config (ou tout ce que vous choisissez de l'appeler), les différents fichiers de configuration intermédiaires doivent avoir une action de construction = None, et copier dans le répertoire de sortie = ne pas copie.

Cela combine les deux options en un seul bloc. Le approprié est exécuté en fonction des conditions. La tâche TransformXml est définie en premier:

<Project>
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="TransformOnBuild" BeforeTargets="PrepareForBuild">
    <TransformXml Condition="Exists('App_Config\app.Base.config')" Source="App_Config\app.Base.config" Transform="App_Config\app.$(Configuration).config" Destination="app.config" />
    <TransformXml Condition="Exists('App_Config\Web.Base.config')" Source="App_Config\Web.Base.config" Transform="App_Config\Web.$(Configuration).config" Destination="Web.config" />
</Target>

Voir si le XDT (web.config) transformer moteur peut vous aider. Actuellement, il est uniquement pris en charge nativement pour les projets web, mais techniquement, rien ne vous empêche de l'utiliser dans d'autres types d'applications. Il existe de nombreux guides sur la façon d'utiliser XDT en éditant manuellement les fichiers du projet, mais j'ai trouvé un plugin qui fonctionne très bien: https://visualstudiogallery.msdn.microsoft.com/579d3a78-3bdd-497c-bc21-aa6e6abbc859

Le plugin aide seulement à configurer la configuration, ce n'est pas nécessaire pour construire et la solution peut être construite sur d'autres machines ou sur un serveur de construction sans que le plugin ou d'autres outils soient nécessaires.

, j'ai résolu ce sujet avec la solution que j'ai trouvé ici: http://www.blackwasp.co.uk/SwitchConfig.aspx

En bref ce qu'ils disent qu'il est: "en ajoutant un événement post-build.[...] Nous devons ajouter ce qui suit:

if "Debug"=="$(ConfigurationName)" goto :nocopy
del "$(TargetPath).config"
copy "$(ProjectDir)\Release.config" "$(TargetPath).config"
:nocopy

Après quelques recherches sur la gestion des configs pour le développement et les builds, j'ai décidé de lancer le mien, je l'ai rendu disponible sur bitbucket à: https://bitbucket.org/brightertools/contemplate/wiki/Home

Ces fichiers de configuration multiples pour plusieurs environnements, c'est un outil de remplacement d'entrée de configuration de base qui fonctionnera avec n'importe quel format de fichier basé sur du texte.

J'espère que cela aide.

J'ai entendu de bonnes choses à propos de SlowCheetah, mais j'ai été incapable de le faire fonctionner. J'ai fait ce qui suit: ajouter une balise am à chacun pour une configuration spécifique.

Ex:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'UAT|AnyCPU'">
    <OutputPath>bin\UAT\</OutputPath>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <AppConfig>App.UAT.config</AppConfig>
  </PropertyGroup>