Web.config transformation change path to appsettings

2
votes

I have a web.config file that has the connectionstring & appsettings in a debug file like so:

<connectionStrings configSource="config\connectionStrings-debug.config" />
<appSettings configSource="config\AppSettings-debug.config" />

but when I go to deploy, I have manually change this to the prod value:

<connectionStrings configSource="config\connectionStrings.config" />
<appSettings configSource="config\AppSettings.config" />

I was looking at transformations, but I don't know how I'd use it in this situation as every example was trying to alter a value not a path to a file.

2
c#asp.netweb-configweb-config-transform
One way I've seen this done is to leave the configSource alone (which means all environments have the same path to the secondary file). Then have a post-build event to copy the "debug" versions in your development environment to the common location. And a deployment process that generates environment-specific versions. - Joe

2 Answers

3
votes

You should be able to achieve what you want with a simple transform. e.g.:

<connectionStrings xdt:Transform="SetAttributes" configSource="/new/path" />

The same applies for appSettings.

0
votes

There is a ridiculous number of ways to get around this problem.

The first is to have two connection strings, one for debugging and one for live usage. Use the Name property when declaring your string to give them a unique identifier you can call from your code. Then, you can use If(System.Diagnostics.Debugger.IsAttached) or some other boolean check to determine which string to use at runtime, fetched by that Name.

Another is to pull your web.config and app.config files out of source control (i.e. via VS, adding to a git .ignore file, etc). They're better kept local to the environment where they are used. This is probably the best practice. If you aren't moving the config files around, you can just leave them in place and not have this problem at all.

You can try logic that determines which to use dynamically, preprocessor command #if DEBUG (which determines which code compiles based on which profile you use to do it), etc. The one that will give you the least trouble in the long run, though, is to keep your config files unique to their deployment locations.