Develop Reference

Easiest way to make web.config transforms for deployment?

Anyone have a preferred method for making web.config transforms? I am curious as to what others have done for this. I hate having to continuously update the web.config every time I update or republish.

A few years ago Scott Hanselman gave a solution using pre-build events and batch files:
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
Basically you maintain a separate different configuration for each build and run the batch script pre-build to copy over the Web.Config. The obvious disadvantage is that if you have thirty different build configurations you need thirty different configs, but I find it's nice for projects where you only have two or three configs (like hobby projects, or tools you'll only ever be publishing to internal servers). Plus, it's nice knowing that if you want to you can take extra control of the build process if you want to.

The easiest way to use VS built in support:
You have versions of web.config, for your build versions, (by default Debug and Release)
In the release version you can define transforms what are applied during build. The effective web.config will be the result.

Look into the nuget package for slow cheetah: https://www.nuget.org/packages/SlowCheetah/ This does what you are looking for quite nicely. Be aware that it is for publish transformations only, switching to a different config for local debugging will have no affect.

Create a build configuration for each server you want to deploy to
Example
-Dev Server "copy from debug"-
-Prod Server Debug "copy from debug"-
-Prod Server Release "copy from release"-
Then right click your web.config and select "add config transforms"
You will get new transforms for each configuration you added above.
Now configure your web config transforms for each environment.
Now when you publish you can just select the configuration "Dev, Prod Debug, or Prod Release" and out it goes, no need to update them after that.
Now, the base web.config should always be configured for your local environment, so if you set up in IIS locally it will use web.config without any transforms. Your transforms should transform your local settings in the base web.config to w/e they need to be.

How to pass a parameter to TeamCity Test Runner?

How to pass a parameter to a TeamCity Test Runner?
I've added a build configuration to my teamcity project which copies out a test project from TFS into a local location on the server then it runs the tests with NUnit and display the results.
The problem is that when the tests run from my local pc, they should be using some configurations, when they run from Dev Automated Build and Test Automated Build, they should be using other configurations and all should be in TFS.
For example, BaseUrl and Connection string configurations...
private static readonly string BaseUrl = ConfigurationManager.AppSettings[AppSettingKey.BaseUrl];
Currently, I've added a web.config file to my project which works fine only locally.
So, how to pass these parameters to a TeamCity Build Configuration which is configured on Dev and Test environemnts?
Even if I create separate web.config files (e.g. dev.web.config and staging.web.config), I need a way to tell the Build Configuration to use which configuration file?
Hope the question is clear.
many thanks.

Enlightened, found a solution (should have thought more before submiting a question here)!
I'd just create separate dev.app.config and staging.app.config files then on the "Version Control Settings" page on teamcity I can define rules such as copy this file somewhere.
So I just Copy the file onto the root app.config; that's it!
Rule:
+: SolutionName\Tests\ConfigFiles\Dev\App.config=>SolutionName\Tests\App.config

Consider using the configuration parameter i.e. Build | Release
Use your debug build locally and release on TeamCity. You can do this with an MSBuild parameter (/p:Configuration=Release)
Then use the solution here (How to select different app.config for several build configurations) to use the correct app.config.
I prefer this solution as it keeps the definitions within the solution / projects rather than within the build.
[I'm adding this just for completeness - I had originally followed this approach but then found the other solution]

Rules in Version Control Settings works only for directories so the better approach is to use Build step - command line
Go to Build Step in Settings section
and Add Build Step with following settings
Command Line
Custom script: copy TeamCity.App.config App.config
Execute: Only if all previous steps were successful
Reorder this step and run it before compilation step

Web.Config to not publish certain files

I am curious if it is possible to specify in a web.config file to have visual studio not publish certain files or a certain directory.
The use case that I am trying to solve for is that I have a Test folder on a web app, that provides a series of useful pages for testing and debugging. The pages are very useful for development and qa. However in production they should not exist. What I would like is that when I publish my code with the release config that these files, or the entire folder is not published.

It doesn't really matter where the build conditions are stored, what is important is how you're gonna use them during build/publish. A conditional msbuild script would easily solve your issue - one of build tasks would be to publish/discard files depending of the value of some internal msbuild property and the property value comes from the web.config or any other external source (build script parameter, external XML file, etc.)

You could exclude the folder from your solution, then in publish it would not push it out. Then, if you want it back in your solution, it will still be there. Just right click the folder and include it.

I don't really if this is the "right" way or even possible to do what you are asking.
What I would suggest is to create a second project for your test. I usually go that way and just deploy the second "project" in my test environement.

How to force deployment project to update files during installation of newer version?

I have a Deployment Project for my VS2008 C# application. When installing a new version of my application I want to make sure that files are updated with the files contained in the installer.
I want my installer to automatically remove any old version of the installed application. To do that I follow this procedure (also described here):
Set RemovePreviousVersions to True
Set DetectNewerInstalledVersion to
True
Increment the Version of the
installer
Choose Yes to change the ProductCode
For the assemblies I make sure the AssemblyVersion is set to a higher version:
[assembly: AssemblyVersion("1.0.*")]
Everything is working as intended except for my configuration files (xml files). Since I cannot find a way to "version" these files I cannot make sure that the files are updated if they have been modified on the target machine.
Is there any way to do this and how?
UPDATE: I have tried the approach/solution/workaround found here
Include the file directly in a
project with the following
properties: "Build Action -> Content
file" and "Copy to Output Directory
-> Copy always"
Then add it to the deployment
project via Project
Output->Database->Content Files
Unfortunately it did not make any difference. The behavior is exactly the same.

Add the following property to the Property table of the MSI:
Property REINSTALLMODE with Value amus
Note: This will cause all the files in the MSI (versioned and nonversioned) to overwrite the files that are on the system.

If you're willing to use Orca (there may be another way to do this method, but it's the only one I know of) you may be able to set up RemoveFile directives.
See here for a typically light-weight MSDN document -- could be a starting point.
http://msdn.microsoft.com/en-us/library/aa371201.aspx
Alternatively you could always create a very simple bootstrapper executable that simply calls "msiexec /i REINSTALLMODE=oums" (or whichever command-line switches are needed). Call it setup.exe if you like...
Better option long-term may be to switch to InstallShield or similar -- VS2010 includes a light version of IS and I believe they're moving away from vdproj projects.

Have you tried the approach/solution/workaround found here?
Include the file directly in a
project with the following
properties: "Build Action -> Content
file" and "Copy to Output Directory
-> Copy always"
Then add it to the deployment
project via Project
Output->Database->Content Files

I may be incorrect here, and therefore I am exposing myself to down votes, but here goes anyway!
I believe it is on purpose that config files do not automatically get overwritten; the principle there being that you would not normally want your application's configuration overwritten when you install the new version of the program... at least not without numerous warnings and/or chances to merge configuration first.
Having your application configuration get overwritten by an updated version of a program could make for a very upset end user (in this case, web site admin).
Further, I know that sometimes, the developer may be the person doing the deployment. In such a case, this behavior might not seem so logical when deploying a single site to a single server; but when roles are split and/or you have multiple servers with different configurations, this can be a life saver.

You need to include the new version of your files in your custom installer and manually install these file during Custom Install routine is called
This must be applied to any file that does not have version that can be tracked by the installer.

Why doesn't switching to release in VS set the debug parameter to false in web.config

In VS2008 (and earlier if I'm not mistaking) I have dropdown that lets me choose between Debug and Release mode. All well.
When I switch VS to Release, the debug attribute in my web.config files isn't set to false at all though.
Is this the way it is supposed to be? I am bound to forget to set it to the correct value on deploying.. What measures should I take to make sure this is working like it should?

This is one solution to this problem:
http://blog.aggregatedintelligence.com/2009/04/aspnet-never-again-fear-publishing-your.html

Well your web.config would probably be different for debug and release (connection string, passwords, etc...) but if it's not, look at a postbuild event which would copy over a different file.
Also check this blog post from Scott Guthrie.

Changing release mode will not change web.config, however when you build your web app, it will build the dll for only C# files in release mode where else your web.config's debug on/off is used by IIS to build debug/release version of ASPX markup files.

The build flavour just affects how the code is compiled, it does not affect your configuration files. So yes, to answer your question, this is how it is supposd to be.

The element is a good solution if you have access to the machine.config of your server, which hosts only production applications.
I usually modify the web.config file when generating the deployed files as part of the automated build process. For example web deployment projects can perform web.config section replacement. There are a number of reasons I don't like web deployment projects and I tend to do it with a simple VBS file that modifies the file using MSXML.

The answer you selected from Bobby is not correct. Visual Studio builds the files for you in release while you are in VStudio.
IIS compiles the code at startup with that setting when you deploy. Not the bin directory, but the App_Code and the code behind files.
You should precompile your app before deployment which will compile your code behinds and App_Code dir into dlls in the bin directory.
The deployment tools automatically switch that setting if you set the deployment tool to Release
I use web deployment projects. http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx