583

For Visual Studio 2010 Web based application we have Config Transformation features by which we can maintain multiple configuration files for different environments. But the same feature is not available for App.Config files for Windows Services/WinForms or Console Application.

There is a workaround available as suggested here: Applying XDT magic to App.Config.

However it is not straightforward and requires a number of steps. Is there an easier way to achieve the same for app.config files?

Amitabh
  • 59,111
  • 42
  • 110
  • 159
  • I've come across the following article which looks a bit simpler but I've not tried it myself. http://fknut.blogspot.com/2009/11/appconfig-transformation-with-new.html Also, there is a feature request on MS Connect which might be worth voting up so this gets included across the board in the next SP or version. https://connect.microsoft.com/VisualStudio/feedback/details/564414 – Kim R Jun 14 '10 at 10:56

15 Answers15

638

I tried several solutions and here is the simplest I personally found.
Dan pointed out in the comments that the original post belongs to Oleg Sychthanks, Oleg!

Here are the instructions:

1. Add an XML file for each configuration to the project.

Typically you will have Debug and Release configurations so name your files App.Debug.config and App.Release.config. In my project, I created a configuration for each kind of environment, so you might want to experiment with that.

2. Unload project and open .csproj file for editing

Visual Studio allows you to edit .csproj files right in the editor—you just need to unload the project first. Then right-click on it and select Edit <ProjectName>.csproj.

3. Bind App.*.config files to main App.config

Find the project file section that contains all App.config and App.*.config references. You'll notice their build actions are set to None and that's okay:

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

Next, make all configuration-specific files dependant on the main App.config so Visual Studio groups them like it does designer and code-behind files.

Replace XML above with the one below:

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

4. Activate transformations magic (still necessary for Visual Studio versions such as VS2019)

In the end of file after

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

and before final

</Project>

insert the following XML -- please note there are two steps for the proper transformation to occur:

  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
  <Target Name="BeforeBuild" Condition="Exists('App.$(Configuration).config')">
    <!-- Generate transformed app config and replace it: will get the <runtime> node and assembly bindings properly populated -->
    <TransformXml Source="App.config" Destination="App.config" Transform="App.$(Configuration).config" />
  </Target>
  <Target Name="AfterBuild" Condition="Exists('App.$(Configuration).config')">
    <!-- Generate transformed app config in the intermediate directory: this will transform sections such as appSettings -->
    <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>

Now you can reload the project, build it and enjoy App.config transformations!

FYI

Make sure that your App.*.config files have the right setup like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
     <!--magic transformations here-->
</configuration>
scrat.squirrel
  • 3,607
  • 26
  • 31
Dan Abramov
  • 264,556
  • 84
  • 409
  • 511
  • 4
    Thanks a ton for this! One note, if you add the new .config files to the project after you edit the csproj, they'll show up grouped under App.config. I added one before editing the csproj and essentially ended up with two links to it, one grouped and one solo. – Jeff Swensen Mar 20 '11 at 20:36
  • Are you sure that you removed all original ``s before adding new ``s? This instruction worked for me several times so perhaps you could've missed something. – Dan Abramov Mar 21 '11 at 10:10
  • I removed all of the ``'s related to `.config` files. Did I need to do it for other resources as well? – Jeff Swensen Mar 21 '11 at 13:02
  • Don't think so. Well, anyway I suppose you have the issue solved now? – Dan Abramov Mar 22 '11 at 18:52
  • 1
    @gaearon: Thanks a lot; I've been looking for this for a while - wish I could give more than one upvote. – Aasmund Eldhuset May 10 '11 at 12:37
  • Where does the `$(TargetFileName)` property come from? I'm trying to use this to transform more than just the web.config in my webapp project. – Maslow Jul 05 '11 at 17:31
  • @Maslow: I think that for windows projects it contains output file name (e.g. `SampleApp.exe`). Therefore, `$(TargetFileName).config` becomes `SampleApp.exe.config`, which is exactly the file we wanted to transform. You wouldn't need that for web project because it doesn't have a single output file name. – Dan Abramov Jul 05 '11 at 21:10
  • I've **almost** got this working. The file in the /obj folder is correct, but it's not copied as the final output file. I believe that means the `AppConfigWithTargetPath` bits aren't working for me - is there anything I can do? – Neil Barnwell Aug 12 '11 at 09:23
  • @Neil: Can you try creating a new project and reproducing the problem? – Dan Abramov Aug 12 '11 at 10:27
  • 1
    I fixed my problem it by changing `AfterCompile` to `BeforeCompile`, in the end. To be honest, that would seem to make sense, but I'm not well-up on the chain of commands for the build process. – Neil Barnwell Aug 15 '11 at 12:19
  • 9
    One problem with this approach is that when you look over at the "Publish" tab in the project properties, and then click on the "Application Files" button... you'll notice that app.config, app.Debug.config, app.Release.config are forced to be deployed as part of the Publish process. Sure, you get the correct MyApp.exe.config file too, but I don't want that extra baggage getting deployed. There needs to be a way to keep the app.*.config files in the project as instead of . – Lee Grissom Nov 01 '11 at 18:07
  • 1
    When using a Setup & Deployment Project to deploy a Windows application, the transformed config file is not being deployed. The S&D picks app.config (renames to AppName.exe.config) and deploys that instead. I am still working out how to fix this...anyone have idea's? – empo Nov 15 '11 at 11:26
  • 1
    Just to add to my previous comment, I checked the bin and obj folders and they contain the correctly transformed config file but S&D is not using it. – empo Nov 15 '11 at 11:43
  • 5
    In Target name, AfterCompile didn't work for me, AfterBuild did. – nakhli Apr 09 '12 at 19:43
  • Works great, this is the only solution with VS Express Edition. – Łukasz Wiatrak Mar 04 '14 at 09:01
  • 2
    This should still be the correct answer since the aforementioned addon "SlowCheetah" appears to be unrealiable. – Oliver Weichhold Aug 01 '14 at 10:56
  • 2
    Thanks, this is the way to go. I've been trying to use SlowCheetah in our team but it was unrealiable most of the time. – MonkeyCoder Oct 24 '14 at 08:28
  • An Oscar winner answer. Specially the "Insert the following XML" section. – MHOOS Mar 24 '15 at 15:06
  • 1
    This could possibly be re-updated to no longer refer to slow cheetah, due to its oncoming demise. (its also cleaner IMHO than burdening VS with another add-on.) – Jon Egerton Apr 27 '15 at 16:57
  • Not working for me, I did same and when I publish package as zip file then inside that my app.config file is never transformed. It remains same. – Rupesh Kumar Tiwari Jul 23 '15 at 19:11
  • 8
    The one problem this is leaving out for some is the answer originally taken from Oleg Sych leaves out a key piece. If in your individual app.(env).configs you DO NOT list '' and something like or attributes that do similar things on the setting lines, it will not work. This last bit of information is key and once I added it, poof it all started working. – djangojazz Oct 09 '15 at 16:57
  • ahhhhhh... relief at last!!! FWIW - applied this answer successfully to my VB.NET project in V.S. 2015.. super easy! – bkwdesign May 04 '16 at 19:49
  • 27
    You could replace `v10.0` with `v$(VisualStudioVersion)` to make sure your project does work with all later versions of VS. – Thibault D. May 11 '16 at 09:06
  • 2
    I realize this is five years later but this still seems the best solution with @ThibaultD.'s `v$(VisualStudioVersion)` suggestion, and without changing the `` tags to `` – Auspex Jul 19 '16 at 13:58
  • 1
    Don't give me credit for the `v$(VisualStudioVersion)`, I just copied it from this answer: http://stackoverflow.com/a/18075313/2003763 because I thought it would be better of as a comment. – Thibault D. Jul 20 '16 at 06:04
  • One important note here... don't forget to add ... inside your app.release.config file tags that should be used to replace the debug settings. – matendie Nov 15 '16 at 20:52
  • 1
    In the first line, you can even use this expression `$(VSToolsPath)\Web\Microsoft.Web.Publishing.Ta‌​sks.dll` instead of this one `$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll`. – Rosberg Linhares Mar 01 '17 at 15:26
  • 19
    I had an error MSBuild error MSB3021: Unable to copy file. Could not find file 'obj\Release\ConsoleApp.exe' during the build. So I change a bit the solution to reuse target section instead of creating a new like in the solution – asidis Oct 05 '18 at 05:25
  • 2
    I have not tested this in earlier versions of VS, but in 2019 I had to put the `` and `` bits *before* the existing CSharp target. This was for a WPF app, but it was failing to compile the project not recognizing much of the code and it was also not recognizing any of the project references to other projects in the solution. – David Anderson Apr 18 '19 at 18:24
  • The key here was to convert Content type, it seems transformations do not occur on None type. – Kat Lim Ruiz Jun 26 '19 at 19:42
  • 2
    another comment, this did not work well in Azure Pipelines, what I did in the end, was to use FileTransform task which applies the same transformation, before building the solution, and also disabling it from all csprojs. In some way, it makes sense to do at CI time, and also is more transparent for the build process. – Kat Lim Ruiz Jun 26 '19 at 22:27
  • 2
    ... In some way, it makes sense to do at CI time as it is not compilation per se, it's also more transparent for the build process, and plus, that TransformXml call sometimes did not compile in local environment (probably VS versions mixup). – Kat Lim Ruiz Jun 26 '19 at 22:35
  • 1
    As @KatLimRuiz indicated, it is better to do this in the release pipeline using the official [File Tranform task](https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/file-transform?view=azure-devops). I've put an [answer](https://stackoverflow.com/a/57073008/197591) on another question, which specifically asks how to do this on Azure DevOps, detailing how to do this using said task. – Neo Jul 17 '19 at 09:55
  • I just came back to this again after a few years, and I wish I could upvote again. – tkit Jul 23 '19 at 13:12
  • 1
    For newcomers, you don't need to do all of this anymore, at least in VS2017. Just change the from `None` to `Content` and you can also do this: ` `, instead of adding to each `App.*.config` entry. – jpgrassi Sep 06 '19 at 14:58
  • @jpgrassi I'm editing the answer to include your comment – Esteban Verbel Oct 09 '19 at 16:15
  • @EstebanVerbel, @jpgrassi: When you say you don't have to do step 4 anymore, does that mean not including the `CoreCompile` target? Is that now automatically performed? – end-user Dec 23 '19 at 19:28
  • 1
    @end-user I tried it without step 4 but couldnt get it to work. So I just included step 4. I am using VS 2019 – Andrew Dec 24 '19 at 00:46
  • 1
    For some reason mine is not working, When I run debug it just gives me the app.config values? – Zapnologica Jul 11 '20 at 06:31
  • I'm on VS2019 and it will only work with step 4 included, but that causes errors if you haven't already built the application once. If you remove the obj folder as if building from scratch then you can't build due to files being missing. – D. Hodge Oct 22 '20 at 13:54
  • @D.Hodge If you change CoreCompile to AfterCompile it works fine. – Keith Banner Feb 16 '21 at 20:40
  • 1
    On the VS19, don't forget to change the 4th step. ` – hastrb Apr 09 '21 at 08:37
  • Nice. Also add `` so Clean still cleans. – Heath Raftery Dec 04 '22 at 23:12
427

This works now with the Visual Studio AddIn treated in this article: SlowCheetah - Web.config Transformation Syntax now generalized for any XML configuration file.

You can right-click on your web.config and click "Add Config Transforms." When you do this, you'll get a web.debug.config and a web.release.config. You can make a web.whatever.config if you like, as long as the name lines up with a configuration profile. These files are just the changes you want made, not a complete copy of your web.config.

You might think you'd want to use XSLT to transform a web.config, but while they feels intuitively right it's actually very verbose.

Here's two transforms, one using XSLT and the same one using the XML Document Transform syntax/namespace. As with all things there's multiple ways in XSLT to do this, but you get the general idea. XSLT is a generalized tree transformation language, while this deployment one is optimized for a specific subset of common scenarios. But, the cool part is that each XDT transform is a .NET plugin, so you can make your own.

<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="@*|node()">
  <xsl:copy>           
    <xsl:apply-templates select="@*|node()"/>
  </xsl:copy>
</xsl:template>
<xsl:template match="/configuration/appSettings">
  <xsl:copy>
    <xsl:apply-templates select="node()|@*"/>
    <xsl:element name="add">
      <xsl:attribute name="key">NewSetting</xsl:attribute>
      <xsl:attribute name="value">New Setting Value</xsl:attribute>
    </xsl:element>
  </xsl:copy>
</xsl:template>
</xsl:stylesheet>

Or the same thing via the deployment transform:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
   <appSettings>
      <add name="NewSetting" value="New Setting Value" xdt:Transform="Insert"/>
   </appSettings>
</configuration>
Liam
  • 27,717
  • 28
  • 128
  • 190
Scott Hanselman
  • 17,712
  • 6
  • 74
  • 89
  • Oh that is sweet! Have an app with numerous config files (log4net, nHibernate, web.config) and remembering to change them all was a bit of a pain. I was not looking forward to moving the code into CruiseControl.NET either but looks like that's a breeze too. – DilbertDave Jun 19 '12 at 09:42
  • 10
    FYI, SlowCheetah was a fantastic extension that will now be unsupported after VS 2014. Per the author, Sayed Ibrahim Hashimi, http://sedodream.com/2014/08/11/SlowCheetahIsGoingIntoMaintenanceMode.aspx. – bdeem Oct 01 '14 at 14:30
  • @AnilNatha Where does it say they'll be dropping support? – andrewb Feb 14 '16 at 22:29
  • 5
    @andrewb, I read that [here](https://github.com/sayedihashimi/slow-cheetah/issues/158); however, that was a year ago. After revisiting the thread, and reading the comments, looks like someone has provided a version that works with VS2015 [here](https://visualstudiogallery.msdn.microsoft.com/05bb50e3-c971-4613-9379-acae2cfe6f9e). – Anil Feb 14 '16 at 22:35
  • 3
    Working perfectly with Visual Studio 2017 and Visual STudio 2019 – Guilherme de Jesus Santos May 31 '19 at 11:44
  • 1
    It's [here](https://marketplace.visualstudio.com/items?itemName=vscps.SlowCheetah-XMLTransforms) now – Hugo Freitas Nov 06 '19 at 17:50
  • Does anyone know where to get a version of this which is compatible with Visual Studio 2010? – Sphynx Mar 31 '20 at 14:25
148

Another solution I've found is NOT to use the transformations but just have a separate config file, e.g. app.Release.config. Then add this line to your csproj file.

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

This will not only generate the right myprogram.exe.config file but if you're using Setup and Deployment Project in Visual Studio to generate MSI, it'll force the deployment project to use the correct config file when packaging.

Alec
  • 1,679
  • 1
  • 11
  • 2
  • 6
    The untold wonders of MSBuild. Now I wonder what else is possible. Btw. this works also for clickonce deployments directly from VS (in contrast to higher-voted answers). – Boris B. Jul 15 '13 at 14:05
  • 5
    Changes can become onerous and error prone if the configs contain many entries that are the SAME for all builds. Dealing with an issue right now where one environment's .config missed a change, and of course it was production. – jeepwran Feb 23 '15 at 16:26
  • 1
    Having two copies of config file is not a problem, as long as developers are not the ones who manually maintain it. – anIBMer Aug 26 '15 at 13:00
  • 1
    This is beautiful, works like a charm! I pasted just the `App.Release.config` line inside the existing ``... line saying it was not in the schema or something, but I saved the file anyways and reloaded the project file and did a build in `Release` config and it worked! – Shiva Nov 03 '16 at 18:25
  • 1
    With this, you will lose functionality of settings designer. – Ondřej Apr 10 '17 at 18:32
  • Just an addition: Of course you can change the condition ignoring the Platform (e.g. if you build "Any Platform"): `` – Ole Albers Jul 10 '19 at 09:18
  • This works (very easily) and is IMHO the best option for simple workflows. – Jeremy Morren Jul 27 '20 at 13:22
  • For simple workflows yes, as having to clone large config files over and over again only to change 1 value is not feasible. – iBobb Mar 19 '21 at 14:10
39

Inspired by Oleg and others in this question, I took the solution https://stackoverflow.com/a/5109530/2286801 a step further to enable the following.

  • Works with ClickOnce
  • Works with Setup and Deployment projects in VS 2010
  • Works with VS2010, 2013, 2015 (didn't test 2012 although should work as well).
  • Works with Team Build. (You must install either A) Visual Studio or B) Microsoft.Web.Publishing.targets and Microsoft.Web.Publishing.Tasks.dll)

This solution works by performing the app.config transformation before the app.config is referenced for the first time in the MSBuild process. It uses an external targets file for easier management across multiple projects.

Instructions:

Similar steps to the other solution. I've quoted what remains the same and included it for completeness and easier comparison.

0. Add a new file to your project called AppConfigTransformation.targets

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- Transform the app config per project configuration.-->
  <PropertyGroup>
    <!-- This ensures compatibility across multiple versions of Visual Studio when using a solution file.
         However, when using MSBuild directly you may need to override this property to 11.0 or 12.0 
         accordingly as part of the MSBuild script, ie /p:VisualStudioVersion=11.0;
         See http://blogs.msdn.com/b/webdev/archive/2012/08/22/visual-studio-project-compatability-and-visualstudioversion.aspx -->
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  </PropertyGroup>

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.targets" />

  <Target Name="SetTransformAppConfigDestination" BeforeTargets="PrepareForBuild" 
          Condition="exists('app.$(Configuration).config')">
    <PropertyGroup>
      <!-- Force build process to use the transformed configuration file from now on. -->
      <AppConfig>$(IntermediateOutputPath)$(TargetFileName).config</AppConfig>
    </PropertyGroup>
    <Message Text="AppConfig transformation destination: = $(AppConfig)" />
  </Target>

  <!-- Transform the app.config after the prepare for build completes. -->
  <Target Name="TransformAppConfig" AfterTargets="PrepareForBuild" Condition="exists('app.$(Configuration).config')">
    <!-- Generate transformed app config in the intermediate directory -->
    <TransformXml Source="app.config" Destination="$(AppConfig)" Transform="app.$(Configuration).config" />
  </Target>

</Project>

1. Add an XML file for each configuration to the project.

Typically you will have Debug and Release configurations so name your files App.Debug.config and App.Release.config. In my project, I created a configuration for each kind of enironment so you might want to experiment with that.

2. Unload project and open .csproj file for editing

Visual Studio allows you to edit .csproj right in the editor—you just need to unload the project first. Then right-click on it and select Edit .csproj.

3. Bind App.*.config files to main App.config

Find the project file section that contains all App.config and App.*.config references and replace as follows. You'll notice we use None instead of Content.

<ItemGroup>
  <None Include="app.config"/>
  <None Include="app.Production.config">
    <DependentUpon>app.config</DependentUpon>
  </None>
  <None Include="app.QA.config">
    <DependentUpon>app.config</DependentUpon>
  </None>
  <None Include="app.Development.config">
    <DependentUpon>app.config</DependentUpon>
  </None>
</ItemGroup>

4. Activate transformations magic

In the end of file after

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

and before final

</Project>

insert the following XML:

<Import Project="AppConfigTransformation.targets" />

Done!

Community
  • 1
  • 1
bdeem
  • 899
  • 9
  • 14
  • 1
    Tried in VS Community 2015 RC and it ignores the app.Debug.config file I have. – Khainestar Oct 29 '15 at 12:00
  • I successfully used the accepted answer on one WinForms project .. but for some baffling reason couldn't apply the accepted ans. to another WinForms project (all in the same solution). This answer from @bdeem is my new fave - as it correctly interoperated with my MSI project - big thanks! – bkwdesign Dec 06 '16 at 21:27
  • This didn't seem to work in VS 2015. I updated the VisualStudioVersion from 10 to 12 but no dice. Any ideas? – Sinaesthetic Mar 02 '17 at 04:36
  • @Sinaesthetic Can you give us more details? VS 2015 Ultimate, Community, etc. VB.NET, C#, Any errors? – bdeem Mar 07 '17 at 21:21
  • VS2015 Enterprise. No errors whatsoever. It just doesn't do anything. – Sinaesthetic Mar 07 '17 at 22:59
  • 1) Make sure you include the file as part of the project. Build Action = None. 2) Check your transformation file. It's possible the transformation is incorrect. – bdeem Mar 14 '17 at 22:05
  • Hi, I tried to follow above mentioned steps in my VSTO project type, but unfortunately I could not able to get the transformations in my main app.config file. BTW, I could see that it created the config file as App.config.deploy. Is there some thing I am missing or doing wrong - Here is my config file and CS Project file (https://gist.github.com/Ganeshcse/f3a7369d93b6b06923e9aa848682fa06) – G K Apr 04 '17 at 08:13
35

In my experience, the things I need to make environment-specific are things like connection strings, appsettings and often smpt settings. The config system allows to specify these things in separate files. So you can use this in your app.config/web.config:

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

What I typically do is to put these config-specific sections in separate files, in a subfolder called ConfigFiles (either in the solution root or at the project level, depends). I define a file per configuration, e.g. smtp.config.Debug and smtp.config.Release.

Then you can define a pre-build event like so:

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

In team development, you can tweak this further by including the %COMPUTERNAME% and/or %USERNAME% in the convention.

Of course, this implies that the target files (x.config) should NOT be put in source control (since they are generated). You should still add them to the project file and set their output type property to 'copy always' or 'copy if newer' though.

Simple, extensible, and it works for all types of Visual Studio projects (console, winforms, wpf, web).

jeroenh
  • 26,362
  • 10
  • 73
  • 104
  • I have exactly the same configuration that you have. But I have problems transforming the smtp file. Can you incluye the original and tranformation? These are mine: The base file: ` ` The transformation: ` ` – jgarza Nov 25 '13 at 17:19
  • I'm not sure I understand. In this configuration I don't transform anything, it's just copying files... – jeroenh Nov 25 '13 at 20:40
  • Oh, I didn't see the copy part. I transform the config instead of just copying it. Thanks anyway. – jgarza Nov 26 '13 at 17:50
  • I like this solution. One small suggestion: In the copy example above the source and target arguments for copy should be surrounded by quotes; otherwise Pre-Build will fail for directories with space in their name – vandre Jun 24 '16 at 21:46
30

You can use a separate config file per configuration, e.g. app.Debug.config, app.Release.config and then use the configuration variable in your project file:

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

This will then create the correct ProjectName.exe.config file depending on the configuration you are building in.

Tevin
  • 1,394
  • 16
  • 26
  • Thanks, I didn't use your exact example to solve the problem I was having but your example did get me thinking and led me to another very similar soulution using the Copy task. – jpierson Nov 07 '12 at 20:47
  • Tried this under VS 2015 Community RC and it builds, but then ignores the content of the app.*.config I have added. – Khainestar Oct 29 '15 at 11:53
14

I wrote nice extension to automate app.config transformation like the one built in Web Application Project Configuration Transform

The biggest advantage of this extension is that you don’t need to install it on all build machines

Golan Avraham
  • 330
  • 3
  • 5
  • 1
    Very useful extension, especially now that Slow Cheetah is entering maintenance mode and may not be supported in the future. – dthrasher Feb 27 '15 at 18:36
  • Yeah, folks should stop going to slow cheetah as the solution for this when this functionality is now supported by the transformxml msbuild task. A sw architect on my team introduced slow cheetah in an overzealous way to our project and created debug, stage, and release transforms of all of our configs, most of which needed no transformation. Needless to say, the moment he left I pulled slow cheetah out and now we just use a single transformxml task on the web.config. Ahhhhh, simplicity. Not to say that slow cheetah didn't have its time and place. – HarryTuttle Apr 28 '16 at 16:28
9

Install "Configuration Transform Tool" in Visual Studio from Marketplace and restart VS. You will be able to see menu preview transform for app.config as well.

https://marketplace.visualstudio.com/items?itemName=GolanAvraham.ConfigurationTransform

Taegost
  • 1,208
  • 1
  • 17
  • 26
Agnel Amodia
  • 765
  • 8
  • 18
  • 1
    This works perfectly and requires very little effort or thinking. Much appreciated. thanks. (the 'preview transformation' dosn't work, but the 'add transformations' works perfectly without problem on VS 2017). Also seems to get updates often. – adudley Sep 05 '18 at 20:24
  • 1
    thank you so much for the solution, behind the scene, it does exactly what Dan Abramov has explained above, without getting your hand dirty – Mohammed Dawood Ansari Nov 19 '18 at 13:23
  • This is the ultimate solution. The preview seems to work just fine with VS 2019. – Kyle Jun 07 '19 at 14:33
  • 1
    I love it, but found it did not support other non app.config files without some editing of the csproj. Still great though to see the preview though. – Ian1971 Mar 17 '20 at 11:44
  • 1
    This extension does not seem to work on Visual Studio 2022 – abovetempo Mar 28 '23 at 18:19
5

Just a little improvement to the solution that seems to be posted everywhere now:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
  • that is, unless you are planning to stay with your current VS version forever
Yuri Makassiouk
  • 425
  • 3
  • 16
4

So I ended up taking a slightly different approach. I followed Dan's steps through step 3, but added another file: App.Base.Config. This file contains the configuration settings you want in every generated App.Config. Then I use BeforeBuild (with Yuri's addition to TransformXml) to transform the current configuration with the Base config into the App.config. The build process then uses the transformed App.config as normal. However, one annoyance is you kind of want to exclude the ever-changing App.config from source control afterwards, but the other config files are now dependent upon it.

  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
  <Target Name="BeforeBuild" Condition="exists('app.$(Configuration).config')">
    <TransformXml Source="App.Base.config" Transform="App.$(Configuration).config" Destination="App.config" />
  </Target>
Waggles
  • 304
  • 2
  • 8
2

I have created another alternative to the one posted by Vishal Joshi where the requirement to change the build action to Content is removed and also implemented basic support for ClickOnce deployment. I say basic, because I didn't test it thoroughly but it should work in the typical ClickOnce deployment scenario.

The solution consists of a single MSBuild project that once imported to an existent windows application project (*.csproj) extends the build process to contemplate app.config transformation.

You can read a more detailed explanation at Visual Studio App.config XML Transformation and the MSBuild project file can be downloaded from GitHub.

João Angelo
  • 56,552
  • 12
  • 145
  • 147
1

If you use a TFS online(Cloud version) and you want to transform the App.Config in a project, you can do the following without installing any extra tools. From VS => Unload the project => Edit project file => Go to the bottom of the file and add the following:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterBuild" Condition="Exists('App.$(Configuration).config')">
<TransformXml Source="App.config" Transform="App.$(Configuration).config" Destination="$(OutDir)\$(AssemblyName).dll.config" />

AssemblyFile and Destination works for local use and TFS online(Cloud) server.

Benjamin
  • 333
  • 1
  • 3
  • 14
1

proposed solution will not work when a class library with config file is referenced from another project (in my case it was Azure worker project library). It will not copy correct transformed file from obj folder into bin\##configuration-name## folder. To make it work with minimal changes, you need to change AfterCompile target to BeforeCompile:

<Target Name="BeforeCompile" Condition="exists('app.$(Configuration).config')">
avs099
  • 10,937
  • 6
  • 60
  • 110
1

Note: Due to reputation I cannot comment on bdeem's post. I'm posting my findings as an answer instead.

Following bdeem's post, I did the following (in order):

1. I modified the [project].csproj file. Added the <Content Include="" /> tags to the ItemGroup for the different config files and made them dependent on the original config file.

Note: Using <None Include="" /> will not work with the transformation.

<!-- App.config Settings -->
<!-- Create App.($Configuration).config files here. -->
<Content Include="App.config" />
<Content Include="App.Debug.config">
  <DependentUpon>App.config</DependentUpon>
</Content>
<Content Include="App.Release.config">
  <DependentUpon>App.config</DependentUpon>
</Content>

2. At the bottom of the [project].csproj file (before the closing </Project> tag), I imported the ${MSBuildToolsPath\Microsoft.CSharp.targets file, added the UsingTask to transform the XML and added the Target to copy the transformed App.config file to the output location.

Note: The Target will also overwrite the App.Config in the local directory to see immediate changes working locally. The Target also uses the Name="Afterbuild" property to ensure the config files can be transformed after the executables are generated. For reasons I do not understand, when using WCF endpoints, if I use Name="CoreCompile", I will get warnings about the service attributes. Name="Afterbuild" resolved this.

  <!-- Task to transform the App.config using the App.($Configuration).config file. -->
  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />

  <!-- Only compile the App.config if the App.($Configuration).config file exists. -->
  <!-- Make sure to use the AfterBuild name instead of CoreCompile to avoid first time build errors and WCF endpoint errors. -->
  <Target Name="AfterBuild" Condition="exists('App.$(Configuration).config')">
    <!-- Generate transformed App.config in the intermediate output directory -->    
    <TransformXml Source="App.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="App.$(Configuration).config" />
    
    <!-- Modify the original App.config file with the transformed version. -->
    <TransformXml Source="App.config" Destination="App.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>
</Project>

3. Went back into Visual Studio and reloaded the modified files.

4. Manually added the App.*.config files to the project. This allowed them to group under the original App.config file.

Note: Make sure the App.*.config files have the proper XML structure.

<?xml version="1.0" encoding="utf-8"?>

<!-- For more information on using web.config transformation visit https://go.microsoft.com/fwlink/?LinkId=125889 -->

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings>
    <add name="myConn" connectionString=""; Initial Catalog=; User ID=; Password=;" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
  </connectionStrings>
</configuration>

5. Re-built the project.

Sparky
  • 51
  • 4
1

Yet another variation on @bdeem's answer using Visual Studio 2019 and 2022. My issue was that using that solution, App.config was getting overwritten, and since it's in source control that's not really an option.

The solution for me was to transform the config file directly into the output directory.

  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
  <Target Name="AfterBuild" Condition="Exists('App.$(Configuration).config')">
    <!-- Generate transformed app config to the output directory -->
    <TransformXml Source="App.config" Destination="$(OutDir)\$(TargetFileName).config" Transform="App.$(Configuration).config" />
  </Target>

It has the added benefit of being quite a bit shorter than the original solution.

Daniel
  • 1,695
  • 15
  • 33