Configure Visual Studio 2012 Web Publishing (WPP) for the build server

Question

I am working on creating a build and deployment infrastructure for a large enterprise services infrastructure. We use TFS Build 2012 for our build server, Visual Studio 2012 to create WPP deployment packages, and MSDeploy 2.1 to perform actual deployments. (We cannot use MSDeploy 3 because of a lot of errors with it - NTLM authentication is broken using WMSvc, etc.).

I created the 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 compilation occurs on the build server, OutDir will be different from OutputPath, and WPP will be activated. The line displays the following files:

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

Inside the .zip project:

 Archive.xml Parameters.xml systemInfo.xml 

Question 1 . What is the SourceManifest.xml file and why is it not in the zip package? It seems that the whole reason for creating a zip file package for deployment is that it is completely autonomous. This SourceManifest file is "free" - we can no longer just upload the zip file to our deployment file resource. Why is this not in the package? It also points to specific paths on the build server!

Question 2 . What is the Archive.xml file for? This seems somewhat redundant for SourceManifest.xml - I see a vendor, a number of vendors, etc. The Microsoft documentation mentions "manifest.xml" in the package. This file looks like a manifest, but it is called "archive.xml". Does the file name matter? Is manifest.xml different from archive.xml? How do they relate to SourceManifest.xml, which at the same time looks the same?

Question 3 - what is systemInfo.xml for? It displays a list of all the components that are installed for the IIS role on the build server. For example, if I run the assembly on the command line on my local computer, it lists that .NET 2.0 and 4.0 are installed, as well as several True / False values ​​for the various IIS components on my machine. The problem is that these settings do not affect what I really want to deploy! Does MSDeploy check this file? Can this generation be disconnected? I definitely don't want configuration artifacts on the build server to affect production!

Answer 1

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

You can prevent the creation of cmd and SetParameters files by setting GenerateSampleDeployScript=False . You cannot configure SourceManifest to remove after build, but you can safely do it manually.

SourceManifest.xml is basically a diagnostic artifact. Actually it was -source:manifest=Project.SourceManifest.xml for synchronization -dest:package=Project.zip

archive.xml is the internal representation of the package provider in it. The file is always called archive.xml, and the documentation showing manifest.xml is wrong.

I am not sure how systeminfo.xml is used. I don’t know how to disable functionality, but I also never came across a situation where its properties influenced the deployment.