Home/ Questions/Q 8910973
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T03:49:44+00:00

We’re using the (almost completley undocumented) ‘public API’ for Web Deploy 3 to create

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0