Continuous Learning and Sharing of Team Foundation Server and Application Lifecycle Management RSS 2.0
# Thursday, March 04, 2010

This is Part 4 of my Deployments with TFS series. It has been awhile since I started putting this information together but I haven’t found time to finish this.   A question about building ClickOnce deployments with Team Build 2008 on the MSDN forums was just what I needed to get this posted.

What is ClickOnce?

ClickOnce is a deployment technology that enables you to create self-updating windows based applications that can be installed and run with minimal user interaction.  For a complete overview of ClickOnce, please visit this the ClickOnce Deployment Overview article on MSDN.

Our Requirements

Our requirements contained a couple items that made our deployment more complicated.  The first one is one a configuration management issue that I strongly pushed.  Basically there were two environments, Test and Production.  The ClickOnce was to be built and deployed to the Test server, tested and accepted, and finally pushed to production.  The problem is that Test used different config files than Production.  The thing we didn't want to do is to have to rebuild the application to update the config files, recreate the manifest, and publish to the production.  This had the potential to introduce something different than was tested.Fortunately our Production Release build script was able to copy in the new config files and recreate the manifest and push to production.  The helped ensure the same version of the assemblies tested.  Of course nothing is perfect, we could have still had problems in our config files. :)

The next issue is that we wanted to run Test and Production at the same time to compare if there were problems.  ClickOnce thought these were the same applications so we were unable to run them both.  The solution for this was to use a different key for each environment.  In Test we used a test certificate key that we created, in Production, we used our issued certificate key.  With this, the assemblies could be the same or different versions and ClickOnce treated them as two separate applications.

The Solution

The solution consisted of 4 build scripts

  1. Build and Stage to Test – This builds the application, creates the ClickOnce manifest, and then publishes it to a folder share, ready to be deployed to Test (but not yet).
  2. Deploy to Test – This script copies the ClickOnce application to the web server so the application is available to the testers.  This script also deployed a WCF Windows service.
  3. Stage to Production – This script copied the production config file into the manifest folder, recreated the manifest (with production certificate), and copied the ClickOnce application to a staging folder on a production (so it could be deployed at a later time).
  4. Deploy to Production – This script copies the ClickOnce application from the production staging folder to the production web server.

The “staging” builds could be combined with the “deployment” builds but I believe by separating these it offers the most flexibility.  I will now highlight some of the unique things I had to do to get this all to work.  Unfortunately it wasn’t as simple as using the MSBUILD task.  I think this would work for a demo or simple scenario but not a real world scenario.  There wasn’t any way to change any of the settings.  This offers more options.

Build and Stage To Test

The first part is the properties.  Here I set all of the ClickOnce properties that will be used later on in the build.

  <ClickOnceProduct>Cool Application</ClickOnceProduct>
  <Company>My Company</Company>

The first trick is to edit project file and update the publish url.   This allows the build to edit it but not check out the file and need to check it in.  Do this before the build by overriding the BeforeCompile target.

<Target Name ="BeforeCompile">
  <Message Text="Making csproj file writable"/>
  <Exec Command="attrib -R &quot;$(SolutionRoot)\MyCompany.CoolApp\MyCompany.CoolApp.csproj&quot;"/>

  <Message Text="Replacing PublishUrl"/>

Take the publish.htm file from a manual ClickOnce publish change the version to a tag that can be replaced by the updated version number and check it in to the solution.  After the compile, use the modified version of the publish.htm file copy it to the staging location and then replace it with the version.  MaxVersion is the variable the represents the new version.  I like to keep the assembly version the same as the ClickOnce version.

<Target Name="AfterCompile" Condition="'$(IsDesktopBuild)'!='true'">
  <!-- Copy modified publish htm file to staging publish location -->
  <Copy SourceFiles="$(SolutionRoot)\publish.htm" DestinationFolder="$(PublishUrl)" />

    <WebPage Include="$(PublishUrl)\publish.htm" />


Next, I used a couple of custom tasks I created.  The first was to get the framework version.  I couldn’t figure out a way to do this.  Basically this just returns the .net framework path so I can call Mage.exe.  The second one takes the name of the app and the version to create the manifest folder.  Then it does the heavy lifting to create the ClickOnce application.  We have to do each step to make this work.  There is one thing you will probably noticed is that the setup.exe is renamed to CoolAppSetup.exe.  This was done because there was a policy that users couldn’t run setup.exe. I left out the copying of the files to the staging location before running all of this below.  I had to copy the files individually because this build script also built the WCF service.  You will need to add the appropriate process to copy these.

  1. Generate the application manifest
  2. Sign the application manifest
  3. Rename the source files to .deploy
  4. Generate the deployment manifest
  5. Sign the application manifest (one more time)
  6. Create the bootstrapper

<Target Name="AfterEndToEndIteration">
    <Output TaskParameter="FrameworkPath" PropertyName="FrameworkPath" />
  <CreateManifestName ExecutableName="MyCompany.CoolApp" ExecutableVersion="$(MaxVersion)">
    <Output TaskParameter="ManifestName" PropertyName="ManifestName" />
    <AppPublishDir>$(PublishDir)Application Files\$(ManifestName)</AppPublishDir>

  <Message Text="FrameworkPath = $(FrameworkPath)" />
    Message="Building $(ClickOnceAppName) ClickOnce version: $(VersionNumber)">
    <Output TaskParameter="Id" PropertyName="StepId" />

Generate application manifest
  Command="mage.exe -New Application -TrustLevel FullTrust -ToFile &quot;$(AppPublishDir)\$(ClickOnceExeFile).manifest&quot; -Name &quot;$(ClickOnceAppName)&quot; -Version &quot;$(VersionNumber)&quot; -FromDirectory &quot;$(AppPublishDir)"

Sign application manifest
  <!--<Exec Condition="'$(SigningCertPassword)'==''"
    Command="mage.exe -Sign &quot;$(AppPublishDir)\$(ClickOnceExeFile).manifest&quot; -CertFile &quot;$(SigningCert)&quot;"
    WorkingDirectory="$(SdkPath)"  />-->

  <Exec Condition="'$(SigningCertPassword)'!=''"
      Command="mage.exe -Sign &quot;$(AppPublishDir)\$(ClickOnceExeFile).manifest&quot; -CertFile &quot;$(SigningCert)&quot; -Password &quot;$(SigningCertPassword)&quot;"

Rename source files to .deploy
    <SourceFilesToRename Include="$(AppPublishDir)\**\*.*"
    <SourceFilesToDelete Include="$(AppPublishDir)\**\*.*"


  <Delete Files="@(SourceFilesToDelete)"/>

Generate deployment manifest
  <CreateItem Include="$(AppPublishDir)\$(ClickOnceExeFile).manifest" AdditionalMetadata="TargetPath=Application Files\$(ManifestName)\$(ClickOnceExeFile).manifest">
    <Output TaskParameter="Include" ItemName="ApplicationManifest"/>

  <Message Text="@(ApplicationManifest)" />


Sign application manifest
  <!--<Exec Condition="'$(SigningCertPassword)'==''"
      Command="mage.exe -Sign &quot;$(PublishDir)\$(ClickOnceAppName).application&quot; -CertFile &quot;$(SigningCert)&quot;"
  <Exec Condition="'$(SigningCertPassword)'!=''"
      Command="mage.exe -Sign &quot;$(PublishDir)\$(ClickOnceAppName).application&quot; -CertFile &quot;$(SigningCert)&quot; -Password &quot;$(SigningCertPassword)&quot;"

Generate Bootstrapper
    <BootstrapperFile Include="Microsoft.Net.Framework.3.5">
      <ProductName>Microsoft .NET Framework 3.5</ProductName>
    <BootstrapperFile Include="Microsoft.Windows.Installer.3.1">
      <ProductName>Windows Installer 3.1</ProductName>


  <Copy SourceFiles="$(PublishDir)\Setup.exe" DestinationFiles="$(PublishDir)\CoolAppSetup.exe" />
  <Delete Files="$(PublishDir)\Setup.exe" />


  <OnError ExecuteTargets="MarkBuildStepAsFailed" />

Mark the buildstep as failed
<Target Name="MarkBuildStepAsFailed">

The Deploy Builds are simply a Copy task to copy the files to the web server.  Do this by creating a share to the same location so you can use a UNC.  The production stage build is basically all of the above again but with the production certificate key and copy the new config file(s) to the production stage location.

Looking back on this it seems complex but this is what the publish wizard is doing behind the scenes and offers complete customizing to fit your needs.  I sliced, diced, and renamed items in the scripts above.  I tried to make sure everything is correct.  If there is a typo or something missing, please let me know and will update it.



Thursday, March 04, 2010 11:20:00 AM (Central Standard Time, UTC-06:00)  #    Comments [3] -
ClickOnce | Team Build | Team Foundation Server

Visual Studio ALM MVP
Microsoft Visual Studio ALM MVP
<April 2016>
About the author/Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2016
Mike Douglas
Sign In
Total Posts: 107
This Year: 0
This Month: 0
This Week: 0
Comments: 90
All Content © 2016, Mike Douglas
DasBlog theme 'Business' created by Christoph De Baene (delarou)