By Sarah Weinberger

2013-10-31 23:19:12 8 Comments

I am building a project through the command line and not inside Visual Studio 2013. Note, I had upgraded my project from Visual Studio 2012 to 2013. The project builds fine inside the IDE. Also, I completely uninstalled VS2012 first, rebooted, and installed VS2013. The only version of Visual Studio that I have is 2013 Ultimate.

    39>path_to_project.csproj(245,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 <Import> declaration is correct, and that the file exists on disk.
    39>Done Building Project "path_to_project.csproj" (Clean target(s)) -- FAILED.

Here are the two lines in question:

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

The original second line was v10.0, but I manually changed that to v12.0.

$(VSToolsPath) elongates from what I see to the v11.0 (VS2012) folder, which obviously is not there anymore. The path should have been to v12.0.

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

I tried specifying VSToolsPath in my system environment variables table, but the external build utility still uses v11.0. I tried searching through the registry and that came up with nothing.

Sadly, I do not see any easy way to get the exact command line used. I use a build tool.



@EM-Creations 2018-10-03 15:35:27

In my case I was using the wrong version of MSBuild.exe.

The version you need to use depends on what version of Visual Studio you used to create your project. In my case I needed 14.0 (having used Visual Studio 2015).

This was found at:

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

You can look under:

C:\Program Files (x86)\MSBuild

To find other versions.

@Kris 2017-07-28 14:56:45

I found I was missing the WebApplications folder on my local PC, did not install with Visual Studio 2017 like it had when I was using 2012.

@Jester 2014-10-18 19:10:51

This is closely related but may or may not fix OPs specific issue. In my case I was trying to automate the deployment of an Azure site using VS2013. Building and deploying via VS works, however, using MSBuild showed a similar error around the "targets". Turns out MSBuild is different under VS2013, and is now part of VS and not the .Net Framework (see Basically, use the correct version of MSBuild:

OLD, VS2012


NEW, VS2013

C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe

Newer, VS2015

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Newer still, VS2017 (not fully testing but discovered - they've moved things around a bit)

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe

@Anthony F 2015-04-15 17:09:50

This fixed it for me. Also, similar answer for a similar question here:

@Usman Younas 2017-03-30 14:10:50

In my case i just comment below line by opening .csproj file and did the trick

.<!-- <Import Project="..\PRPJECTNAME.targets" /> -->

My problem may be different but i am dragged here, but this may help someone.

I picked a single web project from my solution and try to open it as a stand alone project which was making issue, after above heck am able to solve issue.

@Joseph Katzman 2017-03-27 16:31:21

I got this error when I install some VS components. Unfortunately none of these answers didn't help me. I use TFS for command development and I have no permissions to edit build definition. I solved this problem by deleting environment variables which called VS110COMNTOOLS and VS120COMNTOOLS. I think it was installed with my VS components.

@Julius Depulla 2017-03-10 17:01:12

Based on TFS 2015 Build Server

If you counter this error ... Error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Open the .csproj file of the project named in the error message and comment out the section below

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

@giammin 2013-11-20 11:54:44

I had the same issue and find an easier solution

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

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

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

As Sielu pointed out 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

@Peter Hedberg 2014-01-14 08:24:55

I got the error using msbuild from command prompt. Removing this part from the project file sovled the problem.

@GiddyUpHorsey 2014-01-22 00:06:01

I was using VS2013 with TFS2012 and this solution worked for me.

@Sielu 2014-03-04 07:43:20

I used this answer and it worked only if I ensured that my *proj file began with <Project ToolsVersion="12" Before I had <Project ToolsVersion="4" and every time I opened the project in VS it added the two nodes again (i.e. it re-migrated the project to latest version).

@Ralph Jansen 2014-03-21 06:54:45

When I did this, my wpp.targets files in my solution didn't work anymore. I only have this problem when I install only VS2013 on a pc and not a server and then use this as a build machine. My own pc has a clean install and I only have installed VS2010 and VS2013 and everything works fine with this piece of config. Even if you choose new project in VS2013 and look at the project file created, the piece of config is also there. So it must be something else...

@giammin 2014-03-21 08:28:51

@RalphJansen yes this is if you have only vs2013

@Ralph Jansen 2014-03-21 10:48:37

@giammin, I already found the solution. DON'T remove the section from your project file. Set the right tools version in your build definition. 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. The config that you suggested to remove is used by other parts of visual studio in your build proces...

@Ralph Jansen 2014-03-21 10:52:10

@giammin 2014-03-21 10:52:39

@RalphJansen this solution works for you because you have vs2010

@Neil 2014-07-17 14:55:01

This worked for me and got me building again with only VS2013 installed

@Colin Pear 2014-08-14 15:35:17

Removing that line seems to break Web Deploy

@Randeep 2015-03-02 19:14:10

I had same issue was solved by using the /p:VisualStudioVersion=12.0 property as recommended above. Thanks

@Demodave 2016-04-04 15:57:52

How do you get to edit build definition?

@giammin 2016-04-07 08:45:14

@Elaine 2016-05-13 03:54:20

upvote for /p:VisualStudioVersion=12.0, it solved my problem in integration with Jenkins

@Pyro 2016-05-17 07:59:16

I also had the same error .. I did this to fix it

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

change to

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

and it's done.

@odyth 2016-02-04 07:28:08

I had tried all of the above solutions and still no luck. I had heard people installing visual studio on their build servers to fix it, but I only had 5gb of free spaces so I just copied C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio to my build server and called it a day. Started working after that, using team city 9.x and visual studio 2013.

@Scott 2014-01-29 01:22:28

I had this problem for our FSharp targets (FSharpTargetsPath was empty).

Many of the paths are built with reference to the VS version.

For various reasons, our build runs with system privileges, and the environment variable "VisualStudioVersion" was only set (by the VS 2013 installer) at the "user" level - which is fair enough.

Ensure that the "VisualStudioVersion" environment variable is set to "12.0" at the level (System or User) that you are running at.

@David Keaveny 2014-02-19 23:29:38

This is probably a common scenario when running a build server (such as CruiseControl or TeamCity), where the service runs under a particular service account which may not even have interactive desktop permissions. This tip solved the issue for me (VS 2013 installed on a clean install of Server 2008 R2, with CruiseControl.NET)

@RossD 2015-01-13 22:10:23

This worked for me on our TeamCity build server.

@WEFX 2018-06-15 18:04:20

Where can I see my "VisualStudioVersion" ?

@Scott 2018-06-16 02:00:35

@WEFX view the environment variables by selecting System from the Control Panel, then select Advanced system settings, and finally click Environment Variables

@Ralph Jansen 2014-03-21 10:51:40

I had this too and you can fix it by setting the tools version in your build definition.

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


If you have more parameters, separate them with a space and not a comma.

@Simon Whitehead 2014-08-14 01:14:06

We just completed an upgrade from TFS 2005 to TFS 2013 and this was our last hurdle. This definitely worked for us and saved me from pulling my hair out. Thanks so much! +1.

@mcdon 2014-08-19 15:57:30

This article by Sayed Ibrahim Hashimi describes the problem in Visual Studio 2010/2012. A command line build uses the sln file format version -1 as the VisualStudioVersion. You can override this value from the command line as Ralph describes, or as a property of the MSBuild task from a build script. I had the same problem with Visual Studio 2013, and overriding VisualStudioVersion resolved the issue.

@JamesQMurphy 2014-09-19 20:39:22

This worked for us as well. We also considered modifying the build template itself, described here, which might be a better option if you have dozens of build definitions.

@Jhayes2118 2014-10-09 18:53:32

this worked for me. I deleted in the csproj files any reference to visualstudioversion and then added that msbuild argument

@Seyed Morteza Mousavi 2014-11-13 05:53:35

It will be works with /p:VisualStudioVersion=12.0

@Tazos333 2014-10-03 05:39:36

You should copy folder WebApplications from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\ to C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\

@ThatBlairGuy 2016-01-07 21:06:24

Or copy just the Microsoft.WebApplication.targets file from a location where Visual Studio 2013 is installed.

@Vishwajit G 2014-09-18 11:15:20

In my case dev environment is VS2013 and I am using TFS 2010. Build was targeted for .NET 4.5.1. I was setting up auto build for CI. whenever I tried workarounds mentioned above - like removing properties group completely or replacing some lines build used to happen in TFS but my publish to azure used to fail with 'MSDeploy' or at times some different error. I was not able to achieve both simultaneously.

So finally I had to pass MSBuild argument to resolve the issue.

Goto Edit build definition > Process > 3. Advanced > MSBuild Arguments (set to) /p:VisualStudioVersion=12.0

It worked for me.

@Imaginary 2014-09-05 14:43:48

I had similar issue. All proposed solutions are just work around for this issue but are not solving source of error. @giammin solution should not be applied if you are using tfs build server as it is just crashed publish functionality. @cat5dev solution - solves issue but do not solve source of it.

I`m almost sure that you are using build process template for VS2012 like ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml these build templates have been made for VS2012 and $(VisualStudioVersion) set to 11.0

You should use build process template for VS2013 ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml which has $(VisualStudioVersion) set to 12.0

This works without any changes in project file.

@Jurijs Kastanovs 2014-08-21 11:36:16

Me - nothing was helping in changing the v11.0 value of VisualStudioVersion variable to v10.0. Changing variable in .csproj file didn't. Setting it through command promt didn't. Etc...

Ended up copying my local folder of that specific version (v11.0) to my build server.

@Alex T. 2014-07-24 15:54:32

Only one thing needs to be done to solve the problem: upgrade TeamCity to version 8.1.x or higher because support for Visual Studio 2012/2013 and MSBuild Tools 2013 was only introduced in TeamCity 8.1. Once you've upgraded your TeamCity modify MSBuild Tools Version setting in your build step accordingly ans the problem will disappear. For more info read here:

@pinus.acer 2014-07-10 11:54:33

I have Visual Studio 2013 installed. This worked for me:

    <VisualStudioVersion Condition="'$(VisualStudioVersion)' != ''">12.0</VisualStudioVersion>`
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>

So I've changed the condition from == to != and the value from 10.0 to 12.0.

@cat5dev 2014-06-03 17:26:38

giammin's solution is partially incorrect. You SHOULD NOT remove that entire PropertyGroup from your solution. If you do, MSBuild's "DeployTarget=Package" feature will stop working. This feature relies on the "VSToolsPath" being set.

  <!-- VisualStudioVersion is incompatible with later versions of Visual Studio.  Removing. -->
  <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> -->
  <!-- VSToolsPath is required by MSBuild for features like "DeployTarget=Package" -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

@Kim Ki Won 2014-05-28 09:18:57

If you migrate Visual Studio 2012 to 2013, then open *.csprorj project file with edior.
and check 'Project' tag's ToolsVersion element.

That's value 4.0
You make it to 12.0

  • From

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="4.0"
  • To

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="12.0"

Or If you build with msbuild then just specify VisualStudioVersion property

msbuild /p:VisualStudioVersion=12.0

@Patrick Desjardins 2014-07-14 13:44:35

The ToolsVersion must not be the only variable to fix this error message because I saw project with ToolsVersion that could not build correctly.

@Mukund 2014-02-14 08:34:16

you will find

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

in csproj file for which this error is appearing. Just remove this from csproj and then build.

@Steve 2014-01-22 20:59:00

Running this in the commandline will fix the problem also. SETX VisualStudioVersion "12.0"

@Sean 2014-07-04 04:00:56

This worked for me and was preferable to modifying the project file.

@Sarah Weinberger 2013-11-20 13:06:53

I was using an external build utility. Think of something like Ants, if I understand the product correctly, just a commercial version. I had to contact the manufacturer for the answer.

As it turns out, there is a global macro in the project, DEVSTUDIO_NET_DIR. I had to change the path to .Net there. They list various visual studio versions as "Actions", which through me off, but all roads lead back to that one global variable behind the scenes. I would list that as a defect against the product, if I had my way, unless I am missing something in my understanding. Correcting the path there fixed the build problem.

@Sarah Weinberger 2013-10-31 23:27:24

I just received a response from Kinook, who gave me a link:

Basically, I need to call the following prior to bulding. I guess Visual Studio 2013 does not automatically register the environment first, but 2012 did, or I did and forgot.

call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86

Hopefully, this post helps someone else.

@Pogrindis 2016-10-05 10:43:23

Thank you SO much, this solved my issue when building nodeJS node-gyp the Cpp default.props was not found! +1

Related Questions

Sponsored Content

2 Answered Questions

[SOLVED] v12.0 folder not found in MSBuild

1 Answered Questions

2 Answered Questions

[SOLVED] Building VS Solution via command prompt

4 Answered Questions

[SOLVED] Build VS2013 on a TFS Build Server With Only VS2013

2 Answered Questions

[SOLVED] Teamcity not using the right MSbuild version

Sponsored Content