Customizing Visual Studio 2012's Web Publishing Pipeline (WPP) for build server

Question

I'm working on creating a build and deployment infrastructure for a large corporate service infrastructure. We're using TFS Build 2012 for our Build Server, Visual Studio 2012 to generate WPP deployment packages, and MSDeploy 2.1 to perform the actual deployments. (We can't use MSDeploy 3 due to a number of bugs with it - NTLM authentication is broken with WMSvc, etc).

I've created a "Project.wpp.targets" file and added the following properties:

<DeployOnBuild Condition="$(DeployOnBuild) == '' And '$(OutDir)' != '$(OutputPath)' ">true</DeployOnBuild>
<WebPublishMethod>Package</WebPublishMethod>
<DeployManagedPipelineMode>Integrated</DeployManagedPipelineMode>
<Disable_CopyWebApplication>True</Disable_CopyWebApplication>

When the compile happens on the build server, OutDir will be different than OutputPath and WPP will be activated. The build outputs the following files:

Project.zip
Project.SetParameters.xml
Project.SourceManifest.xml
Project.deploy.cmd
Project.deploy-readme.txt

Inside project.zip are:

Archive.xml
Parameters.xml
systemInfo.xml

Question 1 - What is the SourceManifest.xml file for, and why isn't it in the zip package? It seems as though the entire reason for creating a zip file package for deployment is so that it's fully self contained. That SourceManifest file is "loose" - we can't just toss a zip file up on our deployment file share any longer. Why isn't it in the package? It also points at specific paths on the build server!

Question 2 - What is the Archive.xml file for? It seems somewhat redundant to SourceManifest.xml - I see a provider, a number of providers, etc. In the Microsoft documentation they mention "manifest.xml" in the package. This file looks like the manifest, but it's called "archive.xml". Does the filename matter? Is manifest.xml different than archive.xml? How do they relate to SourceManifest.xml, which looks similar yet different at the same time?

Question 3 - what is systemInfo.xml for? It appears to list all of the components installed for the IIS role on the build server. For example, if I run the build at command line on my local machine, it lists that .NET 2.0 and 4.0 are installed and a number of True/False values for the various IIS components on my machine. The problem is those settings have no bearing on what I actually want deployed! Does MSDeploy ever look at this file? Can it's generation be disabled? I definitely do not want configuration artifacts from the build server affecting production!

Answer 1

The zip package generated is self sufficient and can be used with msdeploy.exe without any of the other files in the directory.

You can prevent the cmd and SetParameters files from being generated by setting GenerateSampleDeployScript=False. You cannot configure SourceManifest to be deleted after a build, but you can safely do it manually.

SourceManifest.xml is basically a diagnostic artifact. In reality, it was the -source:manifest=Project.SourceManifest.xml to the sync's -dest:package=Project.zip

archive.xml is the package provider's internal representatio of what's in it. The file is always called archive.xml and the documentation mentioning manifest.xml is mistaken.

I'm not actually sure how systeminfo.xml is used. I don't know of a way to disable the functionality, but I've also never run into a situation where it's properties have affected a deployment.