msbuild /t:Package path/to/project/WebServer.csproj WebServer.csproj.deploy.cmd /p:WebPublishPipelineProjectName=WebServer /p:Configuration=Debug /p:DeployIisAppPath=site/app1
After migration our builds worked fine. But deployed applications did not. After investigating build logs we found out that deploying of all projects were failing since migration onto 4.5 - running generated deploy.cmd file failed with an error. Unfortunately cmd-file's exit code was 0 and TeamCity didn't understand that something broke.
The error was the following:
Error: (01.11.2013 13:25:23) An error occurred when the request was processed on the remote computer. [13:25:23][Step 8/10] Error: The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v4.0'. This application requires 'v4.5'.
"Why of course!", we thought. "We just need to update .NET". But .NET 4.5 was already installed on our server. We remember that 4.5 is "in-place upgrade" for 4.0 and it doesn't change .NET runtime version. So for AppPool in IIS we still have 4.0 as ".NET Framework version".
So what's the problem?
It seems that these's a bug in WebDeploy's tasks for msbuild.
After we build a project which targets v4.5 using msbuild's Package target we'll get a couple of files besides deploy.cmd: SetParamets.xml and SourceManifest.xml. The second one is a manifest file - parameters for manifest provider, which is generated by task ExportManifestFile from Microsoft.Web.Publishing.targets:
Unfortunately manifest file is generated incorrectly. As you can see in example above parameter managedRuntimeVersion for IisApp provider is set as "v4.5". Probably the msbuild task uses property TargetFrameworkVersion from csproj file as a source. But ".NET Framework version" in IIS AppPool can't have such value (because 4.5's runtime version is still 4.0).
To fix the problem just add DeployManagedRuntimeVersion property into your VS-project:
Obviously the bug will be fixed someday but at the moment of VS2013 RTM it's still actual.