The other day I was requested to automate our build process to issue different ClickOnce.aspx) setup for the same application. The main difference was some configuration files pointing to different back end web services.

To start I had to create new build configurations on Team City which used the following settings for the Build Runner:

  1. Targets: Rebuild Publish
  2. Configuration: One per build configurations; e.g DeployClickOnce, integrationDeployClickOnce

Targets and Configuration

Then in my Visual Studio 2008 solution I created several Solution configuration reflecting the different configurations that I needed during my deployment, e.g. DeployClickOnce

Visual Studio 2008 solutions

Then using the project properties from the solution explorer in Visual Studio I had to set all Publish options I was interested in; Publish Location, Installation Folder Url, Install Mode and Settings, Prerequisites…


The issue now is that the Publish Version automatically increment the revision with each publish. But this doesn’t work with our continuous integration server Team City as it would need to checkin the modified file back to subversion. SO a different approach was needed.

The solution I used is to use the Build Number offered by Team City, so I had to modify the MSBuild script to use the the BUILD_NUMBER. To do that, right click in the Solution Explorer on our project and select Edit Project File:


Then you will face the your MSBuild script, and you will have to search for the configuration that we defined some steps before:

  1. <PropertyGroup Condition= ‘$(Configuration)|$(Platform)’ == ‘DeployClickOnce|AnyCPU’ >

Then before the end of the closing PropertyGroupd tag add the following lines:

  1. <ApplicationRevision>$(BUILD_NUMBER)</ApplicationRevision>
  2. <InstallUrl></InstallUrl>
  3. </PropertyGroup>

ApplicationRevision will overwrite the Application revision using the BUILD_NUMBER defined by Team City.

InstallUrl is another configuration that we want to override because we want to create multiple ClickOnce setup installed from different urls. So for DeployClickOnce you will have an InstallURL and for integrationDeployClickOnce you will have another one.

Now we are ready for the final step in which we want to exchange some configuration files related to the different ClickOnce builds and Publish the output to an IIS server so that our testers can access the different ClickOnce package for the different stages.

ClickOnce secure the different files that are created with checksums so that they cannot be mitigated during the installment transfer. So the only option we have to be able to exchange our configuration files is before compilation. So we had a Target to our MSBuild script:

  1. <Target Name=BeforeCompile>
  2. <CallTarget Targets=ExchangeDefaultSettings ContinueOnError=false />
  3. <CallTarget Targets=ExchangeAppConfig ContinueOnError=false />
  4. </Target>

The BeforeCompile target will be called before each build and will exchange our App.config and another settings file containing stage dependant configuration.

Here is the simple target which exchanges the App.config stored in a configs folder:

  1. <Target Name=ExchangeAppConfig>
  2. <Message Text=####### CONFIG Exchange $(Configuration)|$(Platform) ———# />
  3. <Copy Condition= ‘$(Configuration)’ == ‘DeployClickOnce’
  4. SourceFiles=$(SolutionFolder)\Sources\Application\configs\localhost.App.config
  5. DestinationFiles=$(SolutionFolder)\Sources\Application\App.config
  6. ContinueOnError=false />
  7. <Copy Condition= ‘$(Configuration)’ == ‘integrationDeployClickOnce’
  8. SourceFiles=$(SolutionFolder)\Sources\Application\configs\integration.App.config
  9. DestinationFiles=$(SolutionFolder)\Sources\Application\App.config
  10. ContinueOnError=false />
  11. </Target>

The ExchangeDefaultSettings Target works the same.

So before any compilation of our solution using the DeployClickOnce, integrationDeployClickOnce solution configuration the App.config and the default settings file are exchanged. So after the compilation they will be correct according to the stage that we target.

The final step is to Publish the ClickOnce package created to the IIS server. As we defined the Targets: Rebuild Publish, there will be a Rebuild and then a Publish phase in our build script. So now we have to take care of the Publish target.

So we add a Target Publish as here:

  1. <Target Name=Publish>
  2. <CallTarget Condition= ‘$(Configuration)’ == ‘DeployClickOnce’
  3. Targets=DeployClickOnce
  4. ContinueOnError=false />
  5. <CallTarget Condition= ‘$(Configuration)’ == ‘integrationDeployClickOnce’
  6. Targets=DeployClickOnce
  7. ContinueOnError=false />
  8. </Target>

Which just call a Target DeployClickOnce for the configuration we are interested in: DeployClickOnce and integrationDeployClickOnce.

The DeployClickOnce Target is responsible to xcopy the packages created by the Publish Target to the different IIS path used to host our ClickOnce deployment setup:

  1. <Target Name=DeployClickOnce>
  2. <Message Text=####### Deploy ClickOnce $(Configuration)|$(Platform) ———# />
  3. <Exec Command=xcopy /E /Y $(ClickOnceSrc)*.* $(ClickOnceDestination) />
  4. </Target>

This is achieved by using two variables ClickOnceSrc and ClickOnceDestination which are also defined per solution configuration like the ApplicationUrl and InstallUrl. The destination is a folder on a IIS server which already has a manually customized Publish.htm file.

  1. <PropertyGroup Condition= ‘$(Configuration)|$(Platform)’ == ‘DeployClickOnce|AnyCPU’ >
  2. <ClickOnceSrc>$(TestsFolder)\Output\$(OutputPath)app.publish</ClickOnceSrc>
  3. <ClickOnceDestination>E:\Inetpub\Application</ClickOnceDestination>


  1. <PropertyGroup Condition= ‘$(Configuration)|$(Platform)’ == ‘integrationDeployClickOnce|AnyCPU’ >
  2. <ClickOnceSrc>$(TestsFolder)\Output\$(OutputPath)app.publish</ClickOnceSrc>
  3. <ClickOnceDestination>E:\Inetpub\Application\integration</ClickOnceDestination>

Now you have two build configurations which output two valid ClickOnce setup packages using different stage dependant configurations that your tester can install directly from your ClickOnce web site. And if you have configured the automatic update of the application through the ClickOnce Application Updates then the applciation will be updated automatically when a tester start you application.