External VS2013 build error "error MSB4019: The imported project <path> was not found"
Solution 1
I had the same issue and find an easier solution
It is due to Vs2012 adding the following to the csproj file:
<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.
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:
Solution 2
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
/p:VisualStudioVersion=12.0
If you have more parameters, separate them with a space and not a comma.
Solution 3
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 http://timrayburn.net/blog/visual-studio-2013-and-msbuild/). Basically, use the correct version of MSBuild:
OLD, VS2012
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
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
Solution 4
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.
Solution 5
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.
<PropertyGroup>
<!-- 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>
</PropertyGroup>
...
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Related videos on Youtube
Sarah Weinberger
Connect with me on LinkedIn and Facebook, and follow me on Twitter. Software and Systems Engineering Consulting Services C#.Net, DevExpress, Java, Embedded, Web, WordPress, ... Mobile (all main flavors), Web, Desktop, Client/Server Please visit Butterflyvista Professional Career Coaching with Sarah Weinberger Please visit Butterflyvista Desires Learn to play Beethoven Moonlight sonata on the piano! Universe, bring back Sarah Michelle Geller in Ringer
Updated on December 05, 2020Comments
-
Sarah Weinberger over 3 years
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.
ValidateProjects: 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.
Thoughts?
-
Anthony F about 9 yearsSimilar question here stackoverflow.com/questions/17433904/…
-
user145400 about 7 yearsIn my case, I had to specify the correct VisualStudioVersion in the build event that was building with the WebPublish target.
-
-
Peter Hedberg over 10 yearsI got the error using msbuild from command prompt. Removing this part from the project file sovled the problem.
-
John Mills over 10 yearsI was using VS2013 with TFS2012 and this solution worked for me.
-
David Keaveny about 10 yearsThis 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)
-
Sielu about 10 yearsI 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).
-
LockTar about 10 yearsWhen 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 about 10 years@RalphJansen yes this is if you have only vs2013
-
LockTar about 10 years@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...
-
giammin about 10 years@RalphJansen this solution works for you because you have vs2010
-
Sean almost 10 yearsThis worked for me and was preferable to modifying the project file.
-
Patrick Desjardins almost 10 yearsThe ToolsVersion must not be the only variable to fix this error message because I saw project with ToolsVersion that could not build correctly.
-
Neil almost 10 yearsThis worked for me and got me building again with only VS2013 installed
-
Simon Whitehead over 9 yearsWe 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.
-
Colin Pear over 9 yearsRemoving that line seems to break Web Deploy
-
mcdon over 9 yearsThis 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 over 9 yearsThis 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 over 9 yearsthis worked for me. I deleted in the csproj files any reference to visualstudioversion and then added that msbuild argument
-
Randeep about 9 yearsI had same issue was solved by using the /p:VisualStudioVersion=12.0 property as recommended above. Thanks
-
Anthony F about 9 yearsThis fixed it for me. Also, similar answer for a similar question here: stackoverflow.com/a/19826448/61569
-
ThatBlairGuy over 8 yearsOr copy just the Microsoft.WebApplication.targets file from a location where Visual Studio 2013 is installed.
-
Elaine almost 8 yearsupvote for /p:VisualStudioVersion=12.0, it solved my problem in integration with Jenkins
-
Pogrindis over 7 yearsThank you SO much, this solved my issue when building nodeJS
node-gyp
theCpp default.props
was not found! +1 -
WEFX almost 6 yearsWhere can I see my "VisualStudioVersion" ?
-
Scott almost 6 years@WEFX view the environment variables by selecting
System
from the Control Panel, then selectAdvanced system settings
, and finally clickEnvironment Variables
-
Mohammed EL KALAKHI over 4 yearsI used "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe" instead of "C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" and its worked
-
Matthew Beck over 4 yearsYeah, I'm using an SSDT project (.sqlproj), with VisualStudioVersion = 14.0 in the project file. I installed core 3.1, which set my env vars for the targets to God only knows where. Using the msbuild in the folder you suggested worked like a charm!
-
Raf over 2 yearsYou will have a risk that your solution will not be published with latest changes inside.
-
Raf over 2 yearsYou will have a risk that your solution will not be published with latest changes inside.