Publish an Azure Web Site from the Command Line

Azure Web Sites, though still in preview, are a great way of quickly hosting a scalable site on Windows Azure without the overhead  of setting up and maintaining a virtual machine.

One of the great features is the ability to use integrated Publish tools to push the project to the server. No need to manually build, package, transfer and deploy your code – Visual Studio handles everything for you.

Publishing from Visual Studio

Publishing refers to the process of deploying your ASP.NET web site to Azure server, and when working from Visual Studio is very simple.  A few good walkthroughs are available elsewhere so I won’t repeat them here; to summarise:

  1. Download publish settings from the Windows Azure management portal
  2. Configure a publish profile in the ASP.NET project
  3. Run the Publish wizard to push to Azure

This is very useful when getting started, but in the real world you don’t want to publish to the server from Visual Studio; you want to do it from your build server having run unit tests, code coverage, etc. etc.

My build server is running TeamCity, so using MSBuild from the command line seems to be a good route to take. Let’s take a look at how we can get MSBuild to run that same publication for us.

Publishing using MSBuild

Of the 3 steps for publishing from Visual Studio, the first two are setup steps that need only be performed once.  As the output from these steps can be saved (and checked into source control), we are only interested in invoking step 3, but before we can do that we need to make a couple of amendments to the publish profile from step 2.

Modifying the Publish Profile

In step 2 above we created a publish profile that is located in the Properties\PublishProfiles folder:

MyProject
 + Properties
   + PublishProfiles
     - DeployToAzure.pubxml

Note: by default, the pubxml file is named something like [AzureSiteName] – Web Deploy.pubxml; I have renamed it here to remove the reference to the site name.

Let’s take a look at that generated XML.

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>MSDeploy</WebPublishMethod>
    <SiteUrlToLaunchAfterPublish>http://[AzureSiteName].azurewebsites.net</SiteUrlToLaunchAfterPublish>
    <MSDeployServiceURL>waws-prod-db3-001.publish.azurewebsites.windows.net:443</MSDeployServiceURL>
    <DeployIisAppPath>[AzureSiteName]</DeployIisAppPath>
    <RemoteSitePhysicalPath />
    <SkipExtraFilesOnServer>True</SkipExtraFilesOnServer>
    <MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
    <UserName>$[AzureSiteName]</UserName>
    <_SavePWD>True</_SavePWD>
    <PublishDatabaseSettings>
	  <!-- omitted for brevity -->
    </PublishDatabaseSettings>
  </PropertyGroup>
  <ItemGroup>
    <MSDeployParameterValue Include="$(DeployParameterPrefix)DefaultConnection-Web.config Connection String" />
  </ItemGroup>
</Project>

Most of the properties here are self explanatory and have obviously come from the fields that were filled out during the the publish wizard in Visual Studio.  We need to make 2 changes to this XML in order to use it from the command line:

  1. Specify the password from the publish settings
  2. Allow unsecure certificates (no idea why, but we get exceptions if we skip this step)

It goes without saying that, because we are going to save a password, be careful where you save this file.  If there is any risk of this publish profile becoming externally visible then do not save the password.

Assuming that you have decided it is safe to store the password, we need to find out what it should be.  Go back to step 1 in the original Visual Studio instructions and find the downloaded publish settings file named [AzureSiteName].azurewebsites.net.PublishSettings.

This file is plain XML and contains profile details for both Web Deploy and FTP publication.  Locate the userPWD attribute on the Web Deploy node and add a Password node with this value to the publish profile. We can also add the AllowUntrustedCertificates node needed to avoid certificate exceptions.

<PropertyGroup>
  <!-- ...as before... -->
	
  <Password>[password from .PublishSettings file]</Password>
  <AllowUntrustedCertificate>True</AllowUntrustedCertificate>
</PropertyGroup>

That’s all we need to change in the publish profile; now let’s take a look at the MSBuild command.

The MSBuild Command

Now that we have the publish profile configured, the MSBuild command is very simple:

msbuild MyProject.sln
 /p:DeployOnBuild=true
 /p:PublishProfile=DeployToAzure
 /p:Configuration=Release

The 3 flags tell MSBuild to deploy once the build completes; to use the DeployToAzure publish profile we have been modifying; and to build in Release mode (assuming you want to publish a release build).

You can run this from the command line on your local machine or as part of your build process and the site will be rebuilt and deployed directly to Azure!

Advertisements

13 thoughts on “Publish an Azure Web Site from the Command Line

  1. Asanka says:

    Really useful article when it comes to deploying from msbuild…
    But in order to use this sort of approach in a build server, do I need to have Windows Azure SDK installed in it?

      • Matt Woodward says:

        I came across this post when trying to resolve some publishing issues with a VS2010 project, when using Teamcity (incl. the AUzre SDK 1.8 publishing options).

        Thought I’d share that I ended up installing the Azure SDK (1.8) on the build server then forcing the “PublishProfileRootFolder” parameter in the Teamcity build configuration. My MSBuild command parameters looked as follows:

        /P:DeployOnBuild=true
        /P:PublishProfile=
        /P:PublishProfileRootFolder=”%teamcity.build.checkoutDir%\Source\Web Application\My Project\PublishProfiles” (where your publish profiles are stored)
        /P:AllowUntrustedCertificate=true
        /P:Password=%env.DomainPassword%

        Without the SDK the publish profiles seemed to be ignored by MSBuild / Teamcity. Without the RootFolder being forced Teamcity seemed to use an incorrect path provided by the MS Web Publishing Targets file.

        Hope this helps somebody in the same boat!

  2. Thank you, mid 2015 I found this still to be the easiest path!
    Followed this guide, set up a build on Visual Studio Online, and every day our testers now have access to the latest bit!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s