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