ASP.Net 5 and Release Management

date_range  22 January 2016

Release Management

So Release Management is finally in public preview so we can all have a play but things aren’t quite as clear cut as they could be if you’re using ASP.Net 5. At least just not yet.

When you build and publish an ASP.Net 5 app it throws the compiled app along with the chosen DNX into a package that can be deployed. Use the Publish wizard like I’ve done here choosing a target profile of File System. This will create a Publish Profile for us to use later on.


Commit the publish profile and this Powershell scrip as Publish.ps1:

This script is derived from the one that is auto-generated by Visual Studio when you choose to publish directly to the Azure App service but with a small tweak. What I found was that because I had multiple hostname bindings on my website (well, anything other than the initial subdomain), the script didn’t find the url that MSDeploy.axd is exposed upon. If, however, you change it to the script above which looks for the .scm. subdomain explicitly in the enabled hostnames on the object returned from the call to the Azure subscription API, that problem should go away

Now we’ll set up the build on VSTS. I’ve got a couple of extra steps here to restore node.js packages then run some Gulp tasks but the rest of it will be of interest. The part of getting a .Net Core application to build is to install a Dot Net Virtual Machine or DNVM. Then restore and packages the application is dependent upon. You can either use this script or alternatively clone the directory it’s in on GitHub and upload it as a task to your VSTS account and use it as a reusable task like I have using TFX.


Now we have all our dependencies we can actually build the thing and put it into a position that we can use it as a reusable package for Release Management. We use a Visual Studio Build step with the following MSBuild arguments:


Replace package with whatever you saved the original publish profile as. We add the compileSource=true so our output doesn’t contain any unnecessary source files. We aren’t going to editing on Production now are we.


Personally, I then zip the package output up to slightly speed up the upload of the artifact from Build and subsequent download using Release. This little Powershell command does the trick and can be executed with a Command Line step with the tool set to powershelll.exe.

-nologo -noprofile -command "\u0026 { Add-Type -A 'System.IO.Compression.FileSystem'; [IO.Compression.ZipFile]::CreateFromDirectory('PUBLISH_OUTPUT_HERE', 'ZIP_NAME_HERE'); }"

Now we upload the Publish.ps1 auto-generated file as an artifact and the website package as a separate file, zipped or not.

So we have some artefacts we can now connect up to Release Management. If you zipped up the package the first thing you’ll want to do unzip it.

-nologo -noprofile -command "\u0026 { Add-Type -A 'System.IO.Compression.FileSystem'; [IO.Compression.ZipFile]::ExtractToDirectory('OUTPUT_DIRECTORY_HERE' }"

All of this has been leading up to the big finale! Deploy the site to an Azure Website. It’s kinda boring how simple this step is; using an Azure Powershell step, call the Publish.ps1 script with the arguments: -packOutput "OUTPUT_DIRECTORY_HERE" -websiteName "AZURE_WEBSITE_NAME_HERE".


Create a release and watch the script call MSDeploy and send the site to your Azure Website.

comments powered by Disqus

chevron_left Archive