Question

We have what I think is a fairly standard build process:
1. Developer: Check in code
2. Build: Polls repo, sees change, and kicks off build that:
3. Build: Updates from repo, Builds w/ MSBuild, Runs unit tests w/ nunit,
4. Build: creates installer package

Our security team allows us to pull from the build server, but does not allow the build server to push. So we generally rdp in, d/l the installers, and run them, which rules out the slick deployment services, so I would need to generate packages instead. I’d like to use MSDeploy, except that we have the following issues:

1. We’re on .net 3.5, and the MSBuild target (Package) that uses MSDeploy requires 4.0. Is there anything I’d need to install other than .net 4.0 RC for this? (Would MSBuild be part of that upgrade?)
2. When I generate packages with MSDeploy, I see that I don’t have just 1 file. There’s a zip, deploy.cmd, SourceManifest.xml, and SetParameters.xml. What are all the other files for, and why wouldn’t they all be in the ‘package’?
3. It sounds as if you can create packages by telling the system to look at a working IIS site. But if the packages are build from a CI environment, aren’t you basically out of luck here? It feels like they designed some of this for small-scale developers deploying from their dev environment. That’s a fine use case, but I’m interested in see what everyone’s enterprise-experience is with the tool

Any suggestions?

Answer 1

If you are not using Visual Studio 2010 for your application then I would suggest that you pick one of the following:

1. Use msdeploy.exe
2. Install Visual Studio 2010 on your build server and us the MSDeploy tasks themselves

Let me explain it a bit more.

Option 1

MSDeploy itself has no dependency on MSBuild so you could install it by itself on your build server to create the packages for you. You can download it from here. After that you can create an MSBuild deployment script using the Exec task to call msdeploy.exe with the command to create your package.

About the second option

The .targets files as well as the tasks for MSDeploy are not deployed with the .NET framework, but with Visual Studio 2010 itself. So if you wanted to leverage any of those you would have to install VS 2010 on your build server.

You mentioned using the Package target in your post. You won’t be able to use that because that target is a part of a bigger build process for .NET 4 projects. What you could do is to create a separate MSBuild file (separate as in not your project file) which uses MSBuild 4 to call the tasks that are delivered with VS 2010 for Web Deployment.

Here I answer your numbered list specifically

1. You would have to install Visual Studio 2010 since those tasks are shipped with VS itself and not the framework.
2. These files are used to interact with your package. Your package presents your application as a whole. The deploy.cmd will invoke msdeploy.exe to perform the deployment for you. SourceManifest.xml and SetParameters.xml are used to customize the deployment of your app. deploy.cmd will use those files when invoking msdeploy.exe. In other words if you want to customize the path to where the web application would be installed you would set that in SetParameters.xml along with other options.
3. Your right the settings can come from IIS, but many developers prefer to use the VS application server instead of IIS. That is my preference. What I would suggest in this case is to deploy your application to an environment which you will use as a template. Make all the IIS settings that you need, create your MSDeploy package and then grab the archive.xml file from the package and use that when you create your own package. Another option is to setup an IIS server which your build process could deploy to, then use MSDeploy to just sync the files that makeup your app, and then once again to generate the package from that IIS server.