85

First some background. At the end of 2012 we migrated our vs2008 solution to vs2010 but we still target .NET 3.5. (I know nothing but the latest and greatest here!)

We hadn't had any issues with this setup until a few weeks ago when people started getting these errors:

"foo.csproj" (Rebuild target) (16:5) ->
  C:\...\foo.csproj(142,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

The interesting thing is that if you look at the project file it references v10 which makes sense because we don't use Visual Studio 2012.

This error hit several of us at once and even on older code branches that haven't changed in months.

I suspect some update got pushed onto our machines that confused things but I don't know what to do about it.

The short term solution has been to install VS 2012 and not use it but I'm hoping for something a little cleaner than that.

drs9222
  • 4,448
  • 3
  • 33
  • 41
  • 17
    I've found that adding "/p:VisualStudioVersion=10.0" to the MSBuild command line makes this go away but it still feels like a hack. – drs9222 Jul 05 '13 at 12:29

11 Answers11

116

I ran into the same issue with Visual Studio 2013. It turns out that I was using the old version of MSBuild--the one that ships with the .NET Framework--from the command line. Microsoft is now releasing MSBuild as part of Visual Studio itself and also as a separate installer (http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx).

The solution was to use the new version of MSBuild.exe located in C:\Program Files (x86)\MSBuild\12.0\Bin. Once I did that, all the targets errors disappeared.

EDIT 1

As mentioned in the comments, each new version of MSBuild brings with it a new directory. For Visual Studio 2015, use C:\Program Files (x86)\MSBuild\14.0\Bin.

EDIT 2

As mentioned in the comments, for Visual Studio 2017, use C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.

NathanAldenSr
  • 7,841
  • 4
  • 40
  • 51
  • 1
    I posted a request on the TeamCity forum to incorporate the new path (a la how NuGet settings are handled). Hopefully they tackle this quickly. – David Peden Nov 15 '13 at 00:30
  • 1
    The direct link in the blog post to the separate tools download is no longer valid. The correct link is: http://www.microsoft.com/en-us/download/details.aspx?id=40760. – David Peden Nov 15 '13 at 00:35
  • 1
    And, just like that, Jetbrains comes to the rescue with version 8.0.5. Official blog post: http://teamcitydev.blogspot.com/2013/11/teamcity-805-bugfix-update.html – David Peden Nov 18 '13 at 18:02
  • 1
    If you've got local Powershell build scripts, you can simply add to your path: `$env:Path = $env:Path + ";C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications"` and use v4 msbuild (You could do this on your build box too) – Chris S Nov 19 '13 at 15:39
  • 4
    Yes! Thank you - this is the proper solution. – Josh M. Feb 27 '14 at 02:01
  • I know this is pretty old but our original situation hasn't changed and this doesn't really apply to my original question. We are still using vs2010 but have this problem when we don't have vs2012 installed. – drs9222 May 28 '14 at 14:43
  • @drs9222 what happened if you tried Waynes answer ? – wal Aug 12 '14 at 11:24
  • I've never tried that one. I know some people are using vs2012 and I assumed that it would just be changed back if I try it. – drs9222 Aug 14 '14 at 15:43
  • I would recommend adding the correct MSBuild directory to your path, so that you can just invoke MSBuild.exe from your scripts, instead of providing the full path. – hendrikswan Oct 27 '15 at 10:09
  • Solved! For VS2015 works with "C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe" – menkow Apr 21 '16 at 11:14
  • with VS2015 you shopuld use "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" – Enny May 11 '16 at 10:19
  • This works w/2015, you just need to update the version folder - as of this date, 14 (as mentioned above) – Dan May 13 '16 at 14:11
  • 1
    For vs2017, it is no longer found in the "program files (x86)\msbuild" folder (15 folder is there but without the exe). It is now at this location: `C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.exe` Note that you have to replace "Enterprise" with the version of VS you have – Yepeekai Mar 20 '17 at 18:16
  • "use the new version of MSBuild.exe" - how do you do this exactly? How do you tell visual studio to use the one you want? – rdans Jul 31 '17 at 09:19
56

If you have a build server that does not have VS2012 installed, you can fix this by

a) installing the MSBuild.Microsoft.VisualStudio.Web.targets package to your solution, and

b) replacing this line in the .csproj file:

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

With this line pointing to the nuget package

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />

EDIT

As @joedragons points out the version in the updated line should match the nuget package version, i.e. replace targets.11.0.2.1 with targets.x.x.x.x for the current version.

Daniel de Zwaan
  • 3,064
  • 25
  • 24
  • 1
    Likewise, great advice! – Kevin Obee Mar 24 '15 at 16:27
  • 2
    Thanks, great solution – Pavel Jul 01 '15 at 19:42
  • 1
    Maybe obvious but the line you replace with should contain the version of the package you install. The one I installed was 12.0.4 so when I put in the replacement import, I got the same error. When I switched to ...Web.targets.12.0.4\...all good=) Thanks so much! – joedragons Jul 24 '15 at 16:37
  • 2
    You no longer need part b of this answer. For some reason SO has rejected my edit to remove the unnecessary details. – bbodenmiller Mar 06 '17 at 17:49
  • 1
    thanks I did the same with the last version MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3 – Ahmed Samir Nov 06 '17 at 08:20
  • HEADSUP: If you have upgraded to VS17+ then using the aforementioned nuget package is bound to SILENTLY break your publishing mechanism (nothing will be generated in the target folder - yet no error will be printed either). This might be because the nuget package in question hasn't been updated as of the time of this writing to support VS17 / MSBuild 15.5. – XDS Apr 24 '18 at 19:11
23

A simple solution to this problem:

Go to the following path:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio

You will see the latest version V10.0, v11.0, v12.0 depending on your Visual Studio 2010, 2012 or 2013 install.

Copy WebApplications folder from either of latest version directory and paste to other.

Your issues should be resolved.

tRuEsAtM
  • 3,517
  • 6
  • 43
  • 83
samdubey
  • 379
  • 3
  • 10
12

I've found that installing the free Visual Studio 2012 Shell (Isolated) installs the WebApplications v11 MSBuild files. Lighter than a full install of Visual Studio 2012 and no licensing concerns.

Void Ray
  • 9,849
  • 4
  • 33
  • 53
Thomas F. Abraham
  • 2,082
  • 1
  • 19
  • 24
8

Wow. We just saw the same thing happen on our build machine. We use VS2010 and target .NET 4.0. Our project files explicitly import the v10.0 version of these targets. With no changes to the code, yesterday the build was fine and today it's failing with a complaint about a missing v11.0 version. The .NET Framework 4.5.1 got installed/updated last night on this build machine as an automatic update. We're going to force v10.0 with the parameter (or env. variable), but this certainly took us by surprise...

UPDATE: What's even more weird, is that it seems to be the case that today's version of msbuild seems to be using the first line of the sln file to determine which VisualStudioVersion to use by default, whereas yesterday's version did not: 

Format Version 12.00

We tested manually changing this to 11.00 and the build started working again.

In our case, even though we're targeting and building everything for 2010/4.0, some devs have been getting ready for VS2012 (since MS claimed that the project files are compatible), and this particular solution was last saved (months ago) in VS2012. Before today, that wasn't causing a problem.

lesscode
  • 6,221
  • 30
  • 58
  • 1
    This helped me much more than the highest voted answer which seems to be about an entirely different situation. – LambdaCruiser Jun 26 '14 at 12:16
  • Same here @LambdaCruiser this answer helped a great deal. I looked at the history of my .sln file and altho the 2nd line read `# Visual Studio 2010` the first line ended with `Format Version 12.00` as at some stage I had upgraded to vs2012 but switch back and forth to vs2010. Like Wayne this problem occurred after running windows update on the CI server – wal Aug 12 '14 at 11:20
6

I had the same issue. Fixed by going through above listed solutions. The issue is caused because appropriate version of Visual Studio Tools (BuildTools) is not available on the Build server. As rightly pointed above, this can be resolved by installing BuildTools but is not the option in my case.

Here is another alternative - use Nuget 

Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3

Identify the start up project and Install the web.targets based on the version of Visual studio being used. The following files will be modified which includes the required changes

In packages.config:

<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />

In .csproj:

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />

Hope this helps!!! Good Luck,

Cheers,

user2964808
  • 143
  • 2
  • 5
  • 1
    Perfect answer - eliminates the need to monkey with csproj file or copying things around on build server. Worked across multiple versions of Visual Studio and MSBuild 2017. I've removed "WebApplication.targets" line manually though - nuget did not remove it automatically. – Gedas Kutka Feb 21 '18 at 23:46
3

Hack, but solved it by copying: c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications*.* to c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications*.*

Wolf5
  • 16,600
  • 12
  • 59
  • 58
1

I got this error in the end of November without making any changes to either the configuration of my TeamCity installation or MSBuild installation or the source code. On my build server Visual Studio isn't even installed, and the change from VS2010 to VS2012 was made in the end of August without any problems at the time.

My MSBuild version is 4.0.30319.18408, my build server is a Windows Server 2008 R2 SP1 with TeamCity v6.5.3.

I solved the issued by simply copying the v11-folder from another build server which was unaffected.

My guess is that this could have happened in two ways:

  1. Something was updated which triggered a deletion of the v11-folder. Could it be a Windows Update to .NET or something?

  2. Something was updated which changed my TeamCity/MSBuild configuration from using v10 to v11 and the builds stop working as the v11 never existed.

I've got a update to .NET Framework 4.5.1 on December 3rd, could that be the reason?

Brgds

Jonas

Jonas
  • 143
  • 6
0

I've recently got stuck with the same problem. And my conclusion is that every version of VS (v10, v11, v12) changes path of build variable, like MSBuildBinPath.

So specifying exact version of VS isn't a hack, because you might not even have appropriate version of files installed. So intead you'd better specify a parameter and use targets that exist on you machine.

In some rare cases you might need to install specific version of VS and Web Deploy package. In my case just version was enough to solve problem.

Johnny_D
  • 4,592
  • 3
  • 33
  • 63
0

You can add the VisualStudioVersion property like this:

<ItemGroup>
  <ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
    <Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
  </ProjectToBuild>
</ItemGroup>
<MSBuild Projects="@(ProjectToBuild)" Targets="Rebuild"/>
Tunaki
  • 132,869
  • 46
  • 340
  • 423
Wallonman
  • 11
  • 1
0

As I was searching how to solve this one, almost everyone recommended either to copy the missing MSBUILD folder or install some SDK of some version.

Luckily, I've found this awesomely helpful post by Donovan Brown : http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!

In a nutshell, the idea is to configure the VisualStudio version your build should use in your Build Definition:

Right Click -> "Edit Build Definition..."

Go to "Procss" -> "3. Advanced"

and set "MSBuild Arguments" with 

/p:VisualStudioVersion=12.0
A. Yosupov
  • 145
  • 4
  • 8