Publishing more than one Azure Cloud Service as part of a TFS build

calendarSep 10, 2014 · 2 min read · Uncategorised  ·
Share on: linkedincopy

Using the process in my previous post you can get a TFS build to create the .CSCFG and .CSPKG files needed to publish a Cloud Service. However, you hit a problem if your solution contains more that one Cloud Service project; as opposed to a single cloud service project with multiple roles, which is not a problem.

The method outlined in the previous post drops the two files into a Packages folder under the drops location. The .CSPKG files are fine, as they have unique names. However there is only one ServiceConfiguration.cscfg, whichever one was created last.

Looking in the cloud service projects I could find no way to rename the ServiceConfiguration file. It looks like it is like a app.config or web.config file i.e. it’s name is hard coded.

The only solution I could find was to add a custom target that is set to run after the publish target. This was added to the end of each .CCPROJ files using a text editor just before the closing 

 1 <Target Name="CustomPostPublishActions" AfterTargets="Publish">  
 2    <Exec Command="IF '$(BuildingInsideVisualStudio)'=='true' exit 0  
 3    echo Post-PUBLISH event: Active configuration is: $(ConfigurationName) renaming the .cscfg file to avoid name clashes  
 4    echo Renaming the .CSCFG file to match the project name $(ProjectName).cscfg  
 5    ren $(OutDir)PackagesServiceConfiguration.\*.cscfg $(ProjectName).cscfg  
 6    " />  
 7  </Target>  
 8   <PropertyGroup>  
 9    <PostBuildEvent>echo NOTE: This project has a post publish event</PostBuildEvent>  
10  </PropertyGroup>

Using this I now get unique name for the .CSCFG files as well as for .CSPKG files in my drops location. All ready for Release Management to pickup

Notes:

  • I echo out a message in the post build event too just as a reminder that I have added a custom target that cannot be seen in Visual Studio, so is hard to discover
  • I use an if test to make sure the commands are only run on the TFS build box, not on a local build. The main reason for this is the path names are different for local builds as opposed to TFS build. If you do want a rename on a local build you need to change the $(OutDir)Packages path to $(OutDir)app.publish. However, it seemed more sensible to leave the default behaviour occur when running locally