I'm continuing my series on building a deployment pipeline. This post gets the ball rolling by creating the project and defining the first command in our deployment pipeline.

Software Requirements

To contnue with this series, you'll need one of two things:

  • Visual Studio 2012
  • Visual Studio 2010 with the Azure SDK 1.71+ (currently 1.8)

File New Project and File Structure

Create a new MVC project called "MvcApplication". Here's an overview of the structure and important files (some won't exist yet) for publishing:

  • MvcApplication.sln
  • MvcApplication/
    • Properties.xml
    • MvcApplication.wpp.targets
    • Properties/
      • PublishProfiles/
        • Package.pubxml
        • Stage.pubxml

All the bold items are special in their naming convention, but we'll describe their purpose as we need them.

Packaging

While WPP still supports the "old way" of packaging (CreatePackageOnPublish=true), the "correct" way to do so is to define a "package" publish profile. To do that:

  1. Right click on the project
  2. Click "Publish..."
  3. Select "<New...>" from the publish profile drop down, call it "Package"
  4. Change the publish method to "Web Deploy Package"
  5. Create a new publish profile called "Package" with an action of "Package"

You'll see that a new file, Properties\PublishProfiles\Package.pubxml, has been created. We'll just leave that alone for now to keep things simple, but we'll be returning here in a future post.

Now we define the first command in our build pipeline:

[sourcecode language="text"]
msbuild MvcApplication.sln /t:Build /p:DeployOnBuild=true;PublishProfile=Package;IsDesktopBuild=false
[/sourcecode]

Now for some options:

  • In Visual Studio 2012, you can change the target to "Publish" and remove "DeployOnBuild" (2010 only supports limited targets for sln files)
  • PublishProfile can be a full path to a pubxml file. If not it will be found in "Properties\PublishProfiles\Package.pubxml"

You also have a few choices about where the zip is generated:

  • By default, the package will be created in bin\_PublishedWebsites\MvcApplication_Package
  • Defining "DefaultPackageOutputDir" to a directory that will contain MvcApplication.zip
  • Defining "PackageFileName" to a full path to the target zip
  • Remove "IsDesktopBuild" from the build command and it will revert to using the absolute package you entered when creating the publish profile ("DesktopBuildPackageLocation")

What's in the box!!?

Let's crack open MvcApplication.zip and see what we've created.

Manifest

The archive.xml file contains the list of providers that will be deployed with the application.

What you'll probably see here is an iisApp provider (deploys content and creates an IIS "application" if the directory isn't one already), and two setAcl providers (one sets read permissions for the App Pool identity and the other for static file access - IUSR).

This file isn't modifyable in it's current (in-zip) state, but understanding it means you can use it to diagnose issues in the future.

Parameters

The properties.xml file contains any deploy-time arguments and how they effect the deployment. In our scenario, WPP has generated two by convention:

"IIS Web Application Name" is the name of the website (or website\virtdir) that we're going to deploy to. If you look carefully, you'll see that the replacement value will be used for both the content deployment and the setAcl provider.

"ApplicationServices-Web.config Connection String" is the connection string value for ApplicationServices (one parameter will be generated per <connectionStrings> entry)

Content

If you navigate into "Content\C_C" and it's children, you'll see that the website content has been added into the package with the full path intact. There's also nothing you can do about this, so keep it in mind in case you write obsenities into your directory structures or something.

It's important to note here, that the content complies with Visual Studio's "Items to deploy" in the "Package/Publish Web" tab of project properties. By default, this includes binary output and any files with a Build Action of "Content".

System Info

Finally, the systemInfo.xml file contains information on which .NET Framework versions and IIS components are installed on the source machine. I'm not 100% sure how this information is used, but I haven't needed to look at this file for any diagnostics so far.