166

Possible Duplicate:
How can I use Web.debug.config in the built-in visual studio debugger server?

I want to use the Web.config transformation that works fine for publish also for debugging.

When I publish a web app, Visual Studio automatically transforms the Web.config based on my current build configuration. How can I tell Visual Studio to do the same when I start debugging? On debug start it simply uses the default Web.config without transformation.

Any ideaa?

Dale K
  • 25,246
  • 15
  • 42
  • 71
Cutter
  • 1,661
  • 2
  • 11
  • 3
  • 21
    This question is *not* a duplicate. The linked "duplicate" http://stackoverflow.com/questions/3305096/how-can-i-use-web-debug-config-in-the-built-in-visual-studio-debugger-server refers to a specific version of Visual Studio. This question does not, and in my opinion this question has more useful answers anyway. – Peter Wone Nov 17 '14 at 23:48

5 Answers5

100

OK, with the understanding that web.debug.config & web.release.config are for package/publish only. I have come up with a way in which to enable what you are trying to do. I've blogged about it at https://devblogs.microsoft.com/aspnet/asp-net-web-projects-web-debug-config-web-release-config/. Here is the summary.

Now let’s see how we can enable what the question asker wants to do.

To recap, when he builds on a particular configuration he wants a specific transform to be applied to web.config. So obviously you do not want to maintain a web.config file, because it is going to be overwritten.

So what we need to do is to create a new file web.template.config, which is just a copy of web.config. Then just delete web.config by using Windows Explorer (don’t delete using Visual Studio because we do not want to delete it from the project).

Note: If you are using a source control provider which is integrated into Visual Studio then you probably want to delete web.config from source control.

Also with this we do not want to use web.debug.config or web.release.config because these already have a well defined role in the Web Publishing Pipeline so we do not want to disturb that. So instead we will create two new files, in the same folder as the project and web.template.config, web.dev.debug.config and web.dev.release.config.

The idea is that these will be the transforms applied when you debug, or run, your application from Visual Studio. Now we need to hook into the build/package/publish process to get this all wired up. With Web Application Projects (WAP) there is an extensibility point that you can create a project file in the same folder with the name {ProjectName}.wpp.targets where {ProjectName} is the name of the project. If this file is on disk in the same folder as the WAP then it will automatically be imported into the project file. So I have created this file. And I have placed the following content:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <!-- Make sure web.config will be there even for package/publish -->
  <Target Name="CopyWebTemplateConfig" BeforeTargets="Build">
    <Copy SourceFiles="web.template.config"
          DestinationFiles="web.config"/>
  </Target>
  
  <PropertyGroup>
    <PrepareForRunDependsOn>
      $(PrepareForRunDependsOn);
      UpdateWebConfigBeforeRun;
    </PrepareForRunDependsOn>
  </PropertyGroup>

  <!-- This target will run right before you run your app in Visual Studio -->
  <Target Name="UpdateWebConfigBeforeRun">
    <Message Text="Configuration: $(Configuration): web.dev.$(Configuration).config"/>
    <TransformXml Source="web.template.config"
              Transform="web.dev.$(Configuration).config"
              Destination="web.config" />
  </Target>

  <!-- Exclude the config template files from the created package -->
  <Target Name="ExcludeCustomConfigTransformFiles" BeforeTargets="ExcludeFilesFromPackage">
    <ItemGroup>
      <ExcludeFromPackageFiles Include="web.template.config;web.dev.*.config"/>
    </ItemGroup>
    <Message Text="ExcludeFromPackageFiles: @(ExcludeFromPackageFiles)" Importance="high"/>
  </Target>
</Project>

Let me explain this a bit. I have created the CopyWebTemplateConfig target which will always copy web.template.config to web.config on build, even if you are not debugging your application in Visual Studio.

This is needed because we still need to support the package/publish process of Visual Studio. Then I extended the property PrepareForRunDependsOn to include the UpdateWebConfigBeforeRun target. This property is used to identify the list of targets which needs to be executed before any managed project is run from Visual Studio.

In this target I am using the TransformXml task to transform web.template.config, using the correct web.dev.***.config file. After that your app starts up using the correct web.config based on your build configuration. After that I have another target ExcludeCustomConfigTransformsFiles, which I inject into the package/publish process via the attribute BeforeTargets=”ExcludeFilesFromPackage”. This is needed because we do not want these files to be included when the application is packaged or published. So that is really all there is to it.

To explain the package/publish process a bit more for this scenario. When you package/publish web.debug.config or web.release.config, depending on build configuration, will still be used. But ultimately the file that it is transforming is web.template.config, so you may have to adjust depending on what you have in that file. Questions/Comments?

Community
  • 1
  • 1
Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178
  • I followed the instructions here but it doesn't seem to work unless I copy the exact config I need (sans transform stuff) into the web.template.config. Any ideas why this is happening (or how to verify which of my web.dev.*.config files is being used to transform? – Mike Cheel Oct 11 '11 at 15:58
  • 2
    Mike, I was having the same problem. However, when I removed the node it works as I needed it to. – Nick Spiers Jan 04 '12 at 20:30
  • I've tried using this as described, but it's still not working. Odd thing is we're using this on other projects and it works without a problem. I've created this stack question http://stackoverflow.com/questions/11763841/web-config-transform-from-web-template-xml-not-working if anyone wants to chime in. – Jerry Aug 01 '12 at 16:45
  • 9
    Learning about that *.wpp.targets file is more valuable than the transform implementation. I've been looking for something like that for a while now. – kenchilada Aug 17 '12 at 20:49
  • 3
    The contribution is great. However, Having tried this out practically, I find the explanation about retaining web.debug.config and web.debug.release WITHOUT having the web.config file included in the solution (which it needs to be) utterly confusing. Also the transforms do not work? And slow cheetahs, f5 > transform > run, is completely misleading too, f5 bound to debug NOT to Build. – brumScouse Jul 04 '13 at 16:10
  • I wrote a blog post about this subject. Maybe t can help someone. http://www.locktar.nl/general/use-config-transforms-when-debugging-your-web-application/ – LockTar Sep 06 '13 at 05:42
  • 3
    Your solution is convoluted because you're working around the fact that IISExpress is launched to run the web in-place in the project folder and you can't transform because the output would clobber the source web.config. Instead of all this fragile and IDE unfriendly business with web.template.config, it would be better to change so that when F5 is pressed: deploy to a folder, launch IISExpress to serve that folder, attach to IISExpress as usual. – Peter Wone May 12 '14 at 05:21
  • Or you could add a build step that backs up web.config, transforms in place and restores web.config when debugging ends, but I'm not sure how to detect the end of debugging. In fact I think I'll stop armchair commentary and try that approach right now. – Peter Wone May 12 '14 at 05:24
  • 2
    @PeterWone concerning the `F5` deploying to a folder: then you have to deal with the `performance, disk space, and cleanup` implications of having your images and Javascripts, Css, or whatever else (maybe videos) copied to another place before you can start debugging. – Maslow Nov 13 '14 at 20:04
  • 1
    @Maslow - If you don't already have an SSD, get one. You won't regret it. – Peter Wone Nov 17 '14 at 05:34
  • 1
    @PeterWone I have nothing but SSDs at home and on my dev machine, but not on the dev build servers (nor on all the developer's machines I think), even with SSDs the extra load of the sheer number of files doing random writes should be a noticeable hit vs. not doing it. – Maslow Nov 17 '14 at 23:23
  • 6
    For anyone struggling with this in later versions of VS, I had to change `` To `` And it all worked after that. – Matti Price Oct 21 '15 at 20:53
  • @Sayed: does the SlowCheetah plugin you built (one year after posting this) make this possible? It only seems to apply to deploys too. – oligofren Mar 15 '16 at 16:38
  • @oligofren status is the same for web projects, no updates. – Sayed Ibrahim Hashimi Mar 16 '16 at 16:49
  • I like the idea of this answer, but I found a simpler implementation at: https://gist.github.com/EdCharbeneau/9135216 – Colin Feb 07 '17 at 22:29
  • @colin that's fine if it works for you. The reason why I didn't do that is because importing that .targets file will modify other parts of the build process. – Sayed Ibrahim Hashimi Mar 02 '17 at 17:18
  • I should have checked the comments first, but in addition to what @MattiPrice says, it seems with VS2015 you can also safely exclude the `CopyWebTemplateConfig` section. – BurnsBA May 05 '17 at 16:49
  • @BurnsBA could u share me your update version of this solution for vs2015? :) – Jota.Toledo May 18 '17 at 09:19
  • 1
    and the great Hashimi came down from mt. redmond, and laid some sweet knowledge of msbuild upon us, for we are unworthy, and the people of the land did prosper. MSBuild chapter 4:31-32 – JJS Jan 09 '19 at 15:02
  • 1
    Trying to apply this solution in visual studio 2017 and 2019. I can't seem to get the "Website Build" option to pick up my *.wpp.targets file. Does this only work for Web Application type projects? Not for websites? – MplsAmigo Jun 24 '19 at 18:51
38

Andrew is on the right path. When you are using this feature here is how it was designed to be used.

web.config This is the config file which developers should use locally. Ideally you should get this to be standardized. For instance you could use localhost for DB strings, and what not. You should strive for this to work on dev machines without changes.

web.debug.config This is the transform that is applied when you publish your application to the development staging environment. This would make changes to the web.config which are required for the target environment.

web.release.config This is the transform that is applied when you publish your application to the "production" environment. Obviously you'll have to be careful with passwords depending on your application/team.

The problem with transforming the web.config that you are currently running is that a transform can perform destructive actions to the web.config. For example it may delete a attributes, delete elements, etc.

Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178
  • 4
    Switching between Release and Debug mode has always had an affect on running an application locally. If you 1) for the transform to be an exception to the rule makes this counter intuitive, – AaronLS Dec 15 '10 at 19:48
  • 19
    What you say is correct, but in my view the design of this feature is limiting. standardised web.config for all developers, in all environments, in any sized team may well not be possible (for anything but the simplest cases). The lack of support for this feature for local builds is a great shame in my view. – MemeDeveloper Jul 03 '12 at 03:55
  • 4
    Further, why is there a problem with the destructive nature of the transformations... web.config and the transforms should all be in SC. Each environment needing a different config should have it's own transform e.g. web.config, web.devgroup1.config, web.devgroup2.config, web.staging.config web.production.config etc. So although web.config would change, nothing would be lost, a get latest + build would result in correct web.config for that environment, nothing lost. – MemeDeveloper Aug 02 '12 at 05:22
  • The transforms modify/replace the Web.config when the project is published so "standardizing it for development" does not work as the "standard" will be wiped out on publishing. – NightWatchman Mar 17 '14 at 18:16
  • 2
    I agree with @MemeDeveloper the notion of a standardised web.config across all developers within a team is completely unrealistic. Microsoft should create a solution that allows developers to have their own settings in the web.config without affecting the web.config checked into source control. – Mick Jan 13 '16 at 23:11
  • 2
    It's insane that these config transforms aren't applied in the debugger when you have the corresponding configuration active. Like AaronLS said, it's a very counter-intuitive exception to the rule. – Triynko Jun 30 '16 at 18:22
  • 1
    It makes even less sense now that we have publish profile config transforms in VS 2013, which are transforms specifically applied over top of project configuration transforms when publishing. There's no reason why we should have both project and publish profile config transforms and both are applied only at publish time. There's no reason for both when they're either both always active (when publishing) or both always inactive (when debugging); it's redundant and confusing. If I'm debugging locally, I should be able to pick my solution configuration to activate the web config transform. – Triynko Jun 30 '16 at 18:26
  • ah ha! I was doing it backwards. It all works after changing my web.config to be local/Dev settings, and the two Web.xxxx.Config files to have my intended Publish settings. My specific need was changing the connectionStrings for a local Db and use the simple Integrated Security. Our cloud deployment uses a different security provider. Maybe we should migrate and use Azure strings for the deployed version. – ripvlan Feb 15 '22 at 17:07
28

You could just use the 'default' web.config as your development/debugging version, and then the web.release.config would of course continue to be the release version, since its transforms are applied when you publish.

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
  • 46
    This doesn't always work well in multi-developer environments (e.g., think connection string). – Ben Collins Aug 02 '11 at 04:04
  • 3
    V. similar to Ben's point... how about multiple development environments, I use three different Dev PCs, for testing different browsers etc, constantly need to change various configs to target different these different setups. – MemeDeveloper Aug 02 '12 at 05:13
  • 5
    Sometimes I need to debug against our integration or staging databases rather than the usual development database. It would be very helpful to have the appropriate transformation applied when running VS's debugger. – Zarepheth Jun 23 '14 at 19:09
  • 4
    @BenCollins is right. As it stands every time you need to change the connection string for debugging purposes, you need to actually change the web.config. Unless you remember to revert the change before checking in this might result in an unwanted revision of the web.config file in source control. If the web.debug.config were applied on build you could simply ignore this file in source control to allow developers to customise their configs without worrying about superfluous revisions on the web.config – Mick Jan 13 '16 at 08:46
  • 1
    this is quite a lazy answer, Im working in a multi dev environment and this approach does not work – Simon Price Jun 26 '18 at 13:04
19

In your debug configuration, add a post-build step, and use it to replace/transform your web.config

Mitch Wheat
  • 295,962
  • 43
  • 465
  • 541
  • If there is some reason you can not do what my answer suggests, this is the next-best option I think. I think the pre-/post-build tasks are sometimes overlooked! – Andrew Barber Oct 13 '10 at 09:40
  • 1
    Since this means you'll be overwriting your original `web.config`, just make sure you aren't permanently losing settings you'll eventually need. Be aware of what this is actually doing. Any permanent transformation that your `web.Debug.config` does to your `web.config`, you'll have to be sure your `web.Release.config` fixes all of it. – Doug S Nov 07 '15 at 22:03
  • 1
    Related Article: https://gist.github.com/EdCharbeneau/9135216 – Suamere Jun 14 '16 at 15:41
15

Although I agree that the simplest approach is usually the best, I can easily imagine a circumstance where for some period of time you want to connect your IDE to a test database instead of your development database. Although you can specify the development connect strings in your default web.config file, it would be really nice to have a Web.Test.config file so that when you swap your build configuration to "Test", you would automatically get the new settings while still in your IDE.

The historical alternative is commenting out one set of connection strings for another, but these new config transforms held out the hope of finally putting a stake in the heart of that ugly practice. Although one default file for development and a transform for release may work much of the time, adding a post-build step to transform the web.config file is the more complete answer in my opinion.

andrewb
  • 5,200
  • 6
  • 36
  • 54
Metaphor
  • 151
  • 2
  • 4
    what is the syntax for post build event to tranform the web config? – Cutter Oct 13 '10 at 12:18
  • You would use commands to, for example, copy a separate file; one way for debug/test, and another way for production (to assure that your publish build doesn't get the test info). – Andrew Barber Oct 13 '10 at 19:30
  • I agree. When debugging a cloud project the configuration works like that. Would be nice with some consistency, like config-transform for Class Libraries etc. – Jonas Stensved Mar 23 '12 at 08:53
  • I use different databases for Debug & Release in a Web service. Look at my solution: It worked for me: http://stackoverflow.com/questions/3305096/how-can-i-use-web-debug-config-in-the-built-in-visual-studio-debugger-server/30357289#30357289 – Mickey Mouse May 20 '15 at 20:07