Web Deploy API - deploy a .NET 4.5 application

Question

We're using the (almost completley undocumented) 'public API' for Web Deploy 3 to create a .zip package of our website and then sync it to a server:

DeploymentBaseOptions destinationOptions = new DeploymentBaseOptions()
{
       UserName = //username,
       Password = //password,
       ComputerName = //a server
};

using (var deploymentObject = DeploymentManager.CreateObject(DeploymentWellKnownProvider.Package, "C:/MyWebsitePackage.zip"))
{
       deploymentObject.SyncParameters.Load(packageParametersFile); \\ contains some connection string information and nothing more.
       DeploymentSyncOptions syncOptions = new DeploymentSyncOptions();

       syncOptions.WhatIf = false;

       deploymentObject.SyncTo(destinationOptions, syncOptions);
}

This code worked perfectly until we installed .NET 4.5 on our production and build servers and upgraded the project we are deploying to 4.5 also. Now we're getting the following error:

The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v4.0'. This application requires 'v4.5'. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_APPPOOL_VERSION_MISMATCH.

Our server definately has .Net 4.5 installed and the and the IIS web site application pool version is '.NET Framework v4.0.30319' (I know it says v4 but .NET 4.5 is an 'in-place' upgrade and replaces 4.0 DLLs with the new version number .30319).

It is possible to resolve this issue when deploying via MSBuild.exe command line (not by creating a package but by syncing directly to a server) by adding the /p:VisualStudioVersion=11.0 flag (which causes a different web application targets file to be used which somehow allows deployment of a .NET 4.5 application).

Does anyone know why Web Deploy API complains like this and how I can resolve this error in the same way as the MSBuild solution?

Adnah

Hello Matt, We're going to look into this report. I will let you know if I need small project to reproduce the problem on our end. Regards, Varun (.NET Framework Compatibility) – Marigraph

Answer 1

Easiest would probably be just including IgnoreDeployManagedRuntimeVersion property from Microsoft.Web.Publishing.targets into the .csproj or as a parameter to MSBuild during /t:package step. Other option might be parameters.xml in project root to make managedRuntimeVersion overwriteable with MSDeploy parameters, or setting it directly in .zip in archive.xml as a predeployment step.

Update (too long to reply as comment):

Well, it's less of a hack than what VS 2012 itself does. Do a publish to IIS from VS (the Web Deploy option) and the package it'll generate will ll be the content of temp folder and a parameters xml, not a zip you get when doing a generic packaging, and runtime version wil be set to 4 even though project is 4.5. IgnoreDeployManagedRuntimeVersion simply will omit it completely. If you do Web Deploy Package option from VS you'll get a zip with 4.5 in the archive.xml and if you try to manually import that VS outputted zip into IIS directly, you'll get the error popup with 4.0 vs 4.5 app pool error, same as the one you get from running msbuild /t:package and msdeploy :sync from command line. VS (devenv) doesn't do it "right", it quietly overwrites the project setting, and it's not MSDeploy's fault as version is set during compilation/packaging (MSBuild/devenv) not during deployment.

By the way, re API docs, yes they are practically nonexistent, but I find the command line docs tolerable (called Web Deploy not MSDeploy, eg http://technet.microsoft.com/en-us/library/dd569089.aspx and others) and mentally mapping those to dotPeek output helps a little.

Sanity

This is what we've have already done just to get the build working - it's not really a fix though is it? More of a hack to suppress that error. – Adnah

See reply in main answer. TL;DR: Yes, it's not ideal but not much different to what VS itself does. – Sanity

Thanks for your further investigation into this - interesting what you said about the way VS 2012 handles this issue. Will wait to see what further investigation from the commenter on the original post brings out too. Thanks! – Adnah

FYI Just noticed there are a couple of more properties from Microsoft.Web.Publishing.targets that affect managedRuntimeVersion in archive.xml, i.e. DeployDefaultTargetFrameworkVersion (defaults to $(TargetFrameworkVersion) which is set to v4.5 in the .csproj) and DeployManagedRuntimeVersion which is blank, setting either of them during t:Package to just 4 should work as well I think. – Sanity

Answer 2

You can try adding this to your project:

<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion>

Isomerous