Build VS2013 on a TFS Build Server With Only VS2013
Asked Answered
N

4

21

I'm setting up a new build server to support a migration of our development team from VS2010 to VS2013. We are not migrating our TFS server just yet so the new build server has been set up as a VS2010 Build Controller with 2 Agents. I have also installed VS2013 on the machine (sledge hammer approach).

All our code has been migrated to target .Net 4.5.1 and compiles fine on a developer's workstation.

Most of our solutions build fine, except the solution that contains web projects. These projects are complaining:

The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found.

The imported project is using the VisualStudioVersion variable in the build process through these two lines:

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

which according to this page:

http://msdn.microsoft.com/en-us/library/vstudio/bb383796.aspx

will be set to "11.0" for both 4.5 and 4.5.1 targets. But the build machine only has a 12.0 version of the above path:

"C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets"

These same .csproj lines seem to be used in a brand new VS2013 project so I'm not sure how this could ever resolve correctly on a build machine.

Nephrosis answered 15/11, 2013 at 13:46 Comment(2)
I'm getting the exact same problem even though the files ARE there in the correct place. Did you find any solution besides the copying you mentioned in the other comment?Tamanaha
Afraid not... copying the files worked and I moved on.Nephrosis
C
26

It is due to Vs2012 adding in csproj file this part:

  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  </PropertyGroup>

You can safely remove that part and your solution will build.

You have to ensure that the .proj file begin with <Project ToolsVersion="12" otherwise the next time you open the project with visual studio 2010, it will add the removed node again.

otherwise if you need to use webdeploy or you use a build server the above solution will not work but you can specify the VisualStudioVersion property in your build script:

msbuild myproject.csproj /p:VisualStudioVersion=12.0

or edit your build definition:

edit build definition to specify the <code>VisualStudioVersion</code> property

Cangue answered 20/11, 2013 at 11:52 Comment(2)
Deleting this part from the project was not working for me. The build succeeded but functionality like config transforms didn't work for me anymore. Setting the toolsversion in your build definition works. See my answer on a related topic: https://mcmap.net/q/73099/-external-vs2013-build-error-quot-error-msb4019-the-imported-project-lt-path-gt-was-not-found-quotFowliang
After our TFS server was upgraded to .NET 4.5 from 4.0, our build definition file no longer worked because the ...\VisualStudio\v11.0\WebApplications\Microsoft.Webapplications.targets file "was not found". We did not have this file under the v11.0 folder, but it was defined under the \v12.0 folder. Your MSBuild property suggestion was applied to our build definiton and now it works! Thanks.Archway
C
15

What you could do is specify the VisualStudioVersion property when running msbuild on the build server

msbuild myproject.csproj /p:VisualStudioVersion=12.0
Cist answered 13/12, 2013 at 10:38 Comment(3)
I would love to try this, but don't know where to change this in the build definition.Borderer
This is very easy to do. Open your build definition and go to the "Process" page. Then under the "3. Advanced" group you have a property called "MSBuild Arguments". Place the parameter there with the following syntax "/p:VisualStudioVersion=12.0". Of course without the quotes. If you have more parameters, separate them with a space and not a comma.Fowliang
See my formatted answer on a related topic: https://mcmap.net/q/73099/-external-vs2013-build-error-quot-error-msb4019-the-imported-project-lt-path-gt-was-not-found-quotFowliang
W
5

I ran into a similar issue...and here's why. Starting with VS2013, MSBuild is shipped as part of Visual Studio instead of the .NET Framework. Refer to this msdn blog.

So to resolve my issue [the correct way], I had to use MSBuild from the "C:\Program Files (x86)\MSBuild\12.0\bin\" instead of "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\"

Withal answered 4/11, 2014 at 12:49 Comment(3)
This should be the accepted answer, worked for me with no changes to .proj filesMazurka
how would you control that on the TFS Build Agent?Loggia
I'm not a TFS user but this link suggests that you can set the ToolPath within your build template.Withal
C
2

You should be able to fix the Tools Version by editing the Build Template.

Open the template .xaml file and find the "Run MsBuild for Project" activity. In the properties there is the option to set the tools version. If needed, you could create a template level property to make it easier to configure.

enter image description here

Cardiac answered 16/11, 2013 at 3:12 Comment(3)
Unfortunately we are not using a workflow based build... we have a an old style build project. Maybe it is time for us to migrate!Nephrosis
In that case, are you calling c:\windows\Framework.NET***\msbuild or the new location under ProgramFiles\Msbuild\Bin?Cardiac
The build machine is new and has only ever has VS2013 installed (not VS2010 nor VS2012) therefore I'm fairly sure it is getting the right version of MSBuild. For now I have simply copied the missing files into the expected folder and the build now runs. Not ideal, nor getting to the root problem, but it keeps me moving forward for now. Thanks.Nephrosis

© 2022 - 2024 — McMap. All rights reserved.