21 November 2010 CI Team

imageIn my last blogpost I showed you some ways how to work with MSBuild. With the help of MSBuild it´s also possible to build a nice Deployment Package. Microsoft released a new tool with VS2010 called MSDeploy. In this Blogpost I´m going to talk about what´s MSDeploy and how does it work in comparison with MSBuild.

Big Picture from MSDeploy

We start with the big picture of MSDeploy. The aim is to build a Deployment Package to make the delivery of software easier. Therefore we have several providers which are used to, for example, pack the data bank or the main ASP.NET Files into one package. Now you are able to publish this package quit easy with MSDeploy. MSDeploy should be installed on the Server too.

At this point I recommend you the blogs of ScottGu and Vishal Joshi (feels like he is THE developer behind MSDeploy).

One of the main advantages of MSDeploy: it´s very easy to bring in new updates. For example you can use the developer-machine of Visual Studio or a Buildserver with a Buildscript.


MSDeploy on the Server

Install MSDeploy with the web platform installer. (look at ScottGus Post). Be careful: the Port of MSDeploy needs to be activated in the Firewall. Every other detail you will find either on ScottGus Post or on IIS.NET here, here or here.

My deploy-try´s till now

So far I build a solution with MSBuild and I used the "_PublishedWebsites" directory. Soon I´m going to write a  post  about the web.conig transformation. But there is a more classy way to do so.

At the moment MSDeploy is created for Web applications. Because of this you do have to think about the Deployment and Packaging from windows services etc. Zwinkerndes Smiley

Easy example

imageIn my example I want to pack a MVC WebApp into a Deployment Package.

Alternative A) Just use Visual Studio. Click right on the project and afterwards "build deployment package". It´s possible if you work just for your own. In my opinion it should be possible to call a build script controlled. At least if you integrate a buildserver you will have no other choice.

Because of this: Alternative B) we write a little MSBuild Script. The output will be the same like in alternative A at the end - just in a script.

In the deployment settings it´s also possible to define the IIS Settings:


But it´s also possible to do so later with parameter. For now, we define the settings before. The site I define should be already created in IIS at the target host. I´m not sure what will happen if this is not given. Zwinkerndes Smiley

Now we are going to talk about the script.


<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Run">
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
	<Target Name="Run">
	<Message Text="Run called." />
			<MSBuild Projects="MSDeployMSBuild.Web\MSDeployMSBuild.Web.csproj"


The most important thing is line 8. Here I call the package target. MSDeploy starts and automatically a Web.config transformation will be done. For property I give the PackageLocation and a help variable named "_PackageTempDir."

As result we have a "Build Deployment Package" or you will have this result with MSBuild:


If you do not define the _PackageTempDir the whole building path will be written down in the Package.SourceManifest.xml. I don´t want this and because of this I apply any other. This path has no influence on the later deployment but I think it looks a little strange Zwinkerndes Smiley

If you don´t want to build the project directly but the solution:

In the last blogposts I always build the whole solution. That´s possible if you use this parameter:

<Solution Include="$(BuildDirFullName)Source\BusinessBingo\BusinessBingo.sln">
      	Platform=Any CPU;

Accomplish the Deployment

If you just call the "MSDeployMSBuild.Web.deploy.cmd" the ReadMe will be opened because there are some information´s absent. Where should be something deploy?

An example for a call:

Package.deploy.cmd /Y /M:http://SERVER_NAME/MSDeployAgentService /U:USERDATEN /P:PASSWORT

Now they try to deploy the package on the defined IIS site on the Server "SERVER_NAME". With the switch /Y the deployment will be started. If you choose /T instead of /Y you are able to make a test - the files won´t be carried.


It doesn´t take a lot to bring the Visual Studio Functionality into a Buildscript. MSDeploy is a big issue. Because of this It´s possible, that not everything is exact on this post but for me it works. Zwinkerndes Smiley