Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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.</p> <p>Update (too long to reply as comment):</p> <p>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.</p> <p>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 <a href="http://technet.microsoft.com/en-us/library/dd569089.aspx" rel="noreferrer">http://technet.microsoft.com/en-us/library/dd569089.aspx</a> and others) and mentally mapping those to dotPeek output helps a little.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload