Lately I have built up our deployment scripts to get them to be a bit more bullet-proof. I have also been creating some new web-based tooling to automate other tasks. I recently created a new web-tool using MVC 4, WebAPI and WCF. I needed to deploy to our test server, and I realized that I did not have MVC 4 and .NET 4.5 installed.

Then it dawned on me – this tool would probably go on our www server too, and that runs Server 2003 – so no .NET 4.5.

I changed up the projects no problem, but it wasn’t that simple. When I built, I ran into an error regarding the version of Microsoft.WebApplication.targets being used. I started digging in the csproj, and I found this bit:

<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)' != ''" />

I banged my head a bit because, from the looks of it, the version is explicitly set to 10.0, but my error kept referencing 11.0? What gives?!? Then I found this post. The important piece for me was this:

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.

I made the switch to VS 2012 a few months ago, and my co-worker and I were just talking about SLN files and some showing the “10” icon while others showed the “11”. I told him, “I am not sure why that is? But I do know that there is version-specific details in the SLN.” Isn’t it funny how the timing on some things can be so uncanny?

So, the workaround referenced within that post was the solution I needed:

msbuild.exe Web.csproj /p:VisualStudioVersion=10.0

All fixed!