47

We recently upgraded our VS 2010 and .NET 4 application to VS 2012 and .NET 4.5. We have a build script to deploy the application on the test server. We have two boxes - one is Windows 8 with VS 2012 (fresh install) and other is Windows 7 with VS 2010 and VS 2012 (installed newly).

When running the build script from Windows 8 box build script is working well and deploys the application to test server. But when deploying the application from Windows 7 box I get the following error:

"C:\Achinth\Build\Work\build\qa1sb.proj" (DeployAll target) (1) ->"C:\Achinth\Build\Work\App\App.csproj" (ResolveReferences;MsDeployPublish target) (2) ->(MSDeployPublish target) -> C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error : Web deployment task failed.((8/19/2012 6:23:41 PM) An error occurred when the request was processed on the remote computer.) [C:\Achinth\Build\Work\App\App.csproj]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error : \r [C:\Achinth\Build\Work\App\App.csproj]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error : (8/19/2012 6:23:41 PM) An error occurred when the request was processed on the remote computer.\r [C:\Achinth\Build\Work\App\App.csproj]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error : The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v4.0'. This application requires 'v4.5'. [C:\Achinth\Build\Work\App\App.csproj]

Looking at the error it looks like that MSBuild is using VS 2010 targets instead of VS 2012, which is causing the error. Since Windows 8 box does not have VS 2010 it is using VS 2012 targets correctly.

Can some one please provide pointers on how to make MSBuild to pick the right version?

Achinth Gurkhi
  • 2,136
  • 4
  • 24
  • 45

5 Answers5

57

In this case you will need to specify the MSBuild property VisualStudioVersion=11.0. I just blogged about this at http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx, I've pasted it below as well for your convenience.

One of the most requested features of Visual Studio 2012 was the ability to open projects in both VS 2012 as well as VS 2010 (requires VS 2010 SP1). In case you haven’t heard we did implement that feature. You may be wondering how we were able to do this and how this may impact you.

If you open the .csproj/.vbproj for a Web Project created in VS2010 you will see the following import statement.

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\
                  v10.0\WebApplications\Microsoft.WebApplication.targets" />

When you open this project in VS 2012 there are a few changes made to your project file to ensure that it can be opened in both VS 2010 SP1 and VS 2012. One of the changes made to the project when it is first loaded in VS 2012 is to add the following to replace that import statement.

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">
    $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

We removed the hard-coded 10.0 and instead used the property VisualStudioVersion. When building in Visual Studio 2012 this value will always be 11.0, but for VS 2010 it doesn’t exist. That is why we defaulted it to 10.0 above. There are some scenarios where building from the command line will require to set this property explicitly. Before we get there let me explain how this property gets set (in this order)

  1. If VisualStudioVersion is defined as an environment variable/global MSBuild property, that is used.
    • This is how VS and the VS developer command prompt set this value
  2. Based on the file format version of the .sln file (toolset used is sln file format –1)
    • To simplify this statement, the .sln file will build with specifying VisualStudioVersion to the value of the version of VS which created the .sln file.
  3. Choose default
    • 10.0 if VS 2010 is installed
    • Highest-versioned sub-toolset version installed

For #2 when you are building a .sln file the value of VisualStudioVersion will be –1 of the Format Version found in the .sln file. The important thing to note here is that if you build a .sln file it will build with the value of VisualStudioVersion corresponding to the version of VS which created the .sln file. So if you create a .sln file in VS2012 and you always build that .sln file the value for VisualStudioVersion will be 11.0. In many cases if you build the .sln file you are good.

If you are building .csproj/.vbproj files w/o going through a .sln file? If you build a web project from the command line (not the developer prompt) then the value for VisualStudioVersion used will be 10.0. That is an artifact of the properties which I showed above. In this case you should pass this in as an MSBuild property. For example

msbuild.exe MyAwesomeWeb.csproj /p:VisualStudioVersion=11.0

In this case I’m passing in the property explicitly. This will always override any other mechanism to determine the value for VisualStudioVersion. If you are using the MSBuild task in a build script, then you can specify the property either in the Properties attribute or the AdditionalProperties attribute. See my previous blog post on the difference between Properties and AdditionalProperties.

If you encounter any funny behavior when building/publishing and you notice that the wrong .targets files are being imported then you may need to specify this property.

Josh M.
  • 26,437
  • 24
  • 119
  • 200
Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178
  • 2
    Adding the "/p:VisualStudioVersion=11.0" did not work for me. I'm using the .NET 4.0 MSBuild.exe to build my VS2012 project, but still the DLL references revert to the VS2012 versions (my project uses the Coded UI test DLL's). – Ciaran Gallagher Aug 29 '12 at 13:00
  • 1
    In the .csproj file, I also changed the 'VisualStudioVersion' number from 10.0 to 11.0 and again attempted a built using MSBuild, and the DLL's still reverted to the version 10 DLL's. – Ciaran Gallagher Aug 29 '12 at 13:06
  • 2
    This long answer, while a wealth of information, did not help me solve the problem in the slightest. Abhishikt's answer below however was very helpful. – Kirk Woll Nov 20 '12 at 21:48
  • @KirkWoll that's because they are two different issues. The info in the other answer is useful but does not directly relate to this question. – Sayed Ibrahim Hashimi Nov 22 '12 at 02:52
  • 2
    My build server, using TeamCity, did not have VS2012 installed on it. So, adding the MSBuild property "/p:VisualStudioVersion=10.0" worked for me!!! NOTE: that version 10.0 is specified, not 11.0! – JTech Apr 08 '13 at 13:22
  • Note that VS2015 still uses `Microsoft Visual Studio Solution File, Format Version 12.00`, so you'll have the same problem - you'll need to use **/p:VisualStudioVersion=14.0** in this case. – White hawk Dec 01 '16 at 14:37
41

from this link.

"Open your *.csproj or *.vbproj web project file in a text editor and add the following line.

<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion>

I added the line just before the line

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

and it deploys without error."

It worked for me.

Kirk Woll
  • 76,112
  • 22
  • 180
  • 195
Abhishikt N. Jain
  • 521
  • 4
  • 5
  • 1
    This worked for me. Thanks a great lot! I also tried the /p:VisualStudioVersion=11.0, but that did not work. – juhan_h Nov 19 '12 at 11:56
  • 4
    This worked for me though I still don't understand the problem. Both my application pool (on windows azure) and my project were targeting .net 4.5. – xtrem Feb 20 '13 at 01:06
  • Thank you for posting this... I used Sayed's suggestions from 2 different posts for 2 different problems and got into a circle of the fix for one undid the other fix (centered around the visualstudioversion 10 or 11). This fixed my issues! – richman64 Aug 21 '13 at 18:38
  • Thanks; this was the 9th thing I tried, and the 1st one that got the job done. – Paul Smith Jun 12 '14 at 23:10
  • It works! It works! I don't understand why, but at least I can move on to the next deployment glitch now. – Ryan Lundy Jun 29 '14 at 23:35
2

I observed that when I use VS2012 Publish Web Deploy Package feature, it generates a .zip file. Inside that zip there is a file called archive.xml that contains a createApp tag with the attribute 'managedRuntimeVersion="v4.0"' . When I use msdeploy.exe to sync it to an iis instance, it works.

However, when I use msbuild.exe to create a web package .zip file, it contains an archive.xml that has 'managedRuntimeVersion="v4.5"'. Trying to deploy this web package to IIS using msdeploy.exe results in the ERROR_APPPOOL_VERSION_MISMATCH error.

As Sayed Ibrahim Hashimi explained here, adding "/p:VisualStudioVersion=11.0" to my msbuild.exe command line effectively forces 'managedRuntimeVersion="v4.0"' in the archive.xml of the resulting web package so it resolves the issue.

sevzas
  • 701
  • 2
  • 5
  • 13
2

For anyone who found this page searching for why msdeploy/webdeploy shows a similar error, I found this to be the solution.

To fix the problem just add DeployManagedRuntimeVersion property into your VS-project:

<targetframeworkversion>v4.5</TargetFrameworkVersion></code>
<DeployManagedRuntimeVersion>v4.0</DeployManagedRuntimeVersion>

From here: http://techblog.dorogin.com/2013/11/deploying-45-projects-with-webdeploy.html

misterduck
  • 106
  • 4
0

In my case WebDeploy was not installed on the build server. So it threw a similar error. I installed WebDeploy and I was golden.

http://www.microsoft.com/en-ca/download/confirmation.aspx?id=25230

mithun_daa
  • 4,334
  • 5
  • 38
  • 50