Develop Reference

Can two CSPROJ exist in the same folder if they both use nuget files?

Summary
I am experiencing a crash in my app which I believe is ultimately caused by having two .csproj files in the same folder. I suspect this may be causing problems since the files in the obj folder do not specify which .csproj they belong to. Is it possible to have two csproj files in the same folder if they both use NuGet references? The files in the obj/ folder seem to suggest that is not a good idea.
Details
I would like to using a library (Common.Standard.csproj) on two separate projects. For reasons which would take a long time to explain, one project needs to reference an older set of nuget packages, while the other project needs newer. To solve this, I created a copy of Common.Standard.csproj which I called Common.MobileStandard.csproj. Both .csproj files are identical except that one references a different set of nuget packages.
My application crashes when I run it, and I have a missing method exception, which I believe is caused by it using the wrong .dll. I've noticed a few other symptoms which I believe are caused by the same root problem. For example, Visual Studio shows a different set of NuGet packages being referenced in the Solution Explorer vs. compared to the .csproj file:
The files shown in Visual Studio's Solution Explorer match the NuGet package references in the other .csproj which is not referenced:
I believe this may be caused by the files stored in the /obj folder. Notice that the "project" files do not specify which .csproj they belong to, so perhaps a single set of "project" files is created despite there being two .csproj files outside of the obj folder?
Am I correct in assuming that this is causing the confusion in Visual Studio, and also the missing method exception at runtime? If so, does that mean that two .csproj files should never share the same folder?
Update 1
I followed suggestions below to use a different in the Common.MobileStandard.csproj so that each .csproj would have its own obj folder, as shown here:
This did produce an objmobile file as expected:
However, the objmobile folder remains empty wnen I build the Common.MobileStandard project. Furthermore, if I delete the contents of the obj folder (the non-mobile one), the nuget packages in Visual Studio get cleared out. It seems as if Visual Studio is always looking in the obj folder rather than in the objmobile, even though the .csproj tells it to look in the objmobile, as shown in the following animation:
I believe the only solution here is to move the .csproj to a separate folder unless I'm mistaken in this being a Visual Studio (or msbuild) bug.
Update 2
It seems that the issue listed in Update 1 is expected behavior. After changing , the following is shown in the output when building the project:
3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(858,5): warning MSB3539: The value of the property "BaseIntermediateOutputPath" was modified after it was used by MSBuild which can lead to unexpected build results. Tools such as NuGet will write outputs to the path specified by the "MSBuildProjectExtensionsPath" instead. To set this property, you must do so before Microsoft.Common.props is imported, for example by using Directory.Build.props. For more information, please visit https://go.microsoft.com/fwlink/?linkid=869650
To fix this, I can create a new file named Directory.Build.props with the following contents:
<Project>
<PropertyGroup>
<MSBuildProjectExtensionsPath>objmobile</MSBuildProjectExtensionsPath>
</PropertyGroup>
</Project>
This does solve the issue in Update 1 (why nuget is still reading from obj) but it brings up a second question - how can I have a different Directory.Build.props for each .csproj file?

It seems I can set BaseIntermediateOutputPath in the .csproj file if I structure it like this:
<Project>
<PropertyGroup>
<BaseOutputPath>bin-example</BaseOutputPath>
<BaseIntermediateOutputPath>obj-example\</BaseIntermediateOutputPath>
<RestorePackagesPath>packages-example\</RestorePackagesPath>
</PropertyGroup>
<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk"/>
<!-- stuff VS normally puts in <Project> -->
<Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk"/>
</Project>
That is, I pulled the Sdk attribute out of the Project tag and converted it to imports, so that I could set things before importing Sdk.props.
I did that based on the page here: https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk?view=vs-2022
In a test rebuild which makes use of nuget packages, this does not touch the obj folder.
It seems .NET Framework projects are structured differently, and I don't think this approach will work there. Hopefully you don't need more than one Framework project in the same directory.

C# Build failed using MSbuild without Visual Studio [duplicate]

Trying to build my project on the build server gives me the following error:
Microsoft (R) Build Engine Version 4.0.30319.1
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.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.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.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.
I solved this problem a few months ago, with installing Visual Studio 2010 on the Build Server. But now I'm setup a new server from scratch, and I want to know if there any better solution to solve this issue.

To answer the title of the question (but not the question about the output you're getting):
Copying the following folder from your dev machine to your build server fixes this if it's just web applications
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications
Remove x86 according to how your build breaks. If you have other project types you will probably need to copy the entire msbuild folder.

The solution would be to install redistributable packages on build server agent. It can be accomplished multiple ways, out of which 3 are described below. Pick one that suits you best.
Use installer with UI
this is the original answer
Right now, in 2017, you can install WebApplication redists with MSBuildTools. Just go to this page that will download MSBuild 2017 Tools and while installation click Web development build tools to get these targets installed as well:
This will lead to installing missing libraries in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications by default
Use command line
disclaimer I haven't tested any of the following proposals
As #PaulHicks and #WaiHaLee suggested in comments, it can also be installed in headless mode (no ui) from CLI, that might actually be preferable way of solving the problem on remove server.
Solution A - using package manager (choco)
choco install visualstudio2017-workload-webbuildtools
Solution B - run installer in headless mode
Notice, this is the same installer that has been proposed to be used in original answer
vs_BuildTools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools --passive

Building and publishing WAPs is not supported if VS is not installed. With that said, if you really do not want to install VS then you will need to copy all the files under %ProgramFiles32%\MSBuild\Microsoft\.
You will need to install the Web Deploy Tool as well. I think that is it.

UPD: as of VS2017, there is workload in Build Tools that eliminates this problem completely. See #SOReader answer.
If you'd prefer not to modify anything on build server, and you still want the project to build right out of source control, it might be a good idea to put the required binaries under source control. You'll need to modify the imports section in your project file to look like this:
<Import Project="$(SolutionDir)\BuildTargets\WebApplications\Microsoft.WebApplication.targets" />
<Import Condition="false" Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
The first line is the actual import from the new location that is relative to the solution directory. The second one is a turned-off version (Condition="false") of the original line that allows for Visual Studio to still consider your project to be a valid Web Application Project (that's the trick that VS 2010 SP1 does itself).
Don't forget to copy the C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplications to BuildTargets folder under your source control.

You can also use the NuGet package MSBuild.Microsoft.VisualStudio.Web.targets, referencing them within your Visual Studio project(s), then change your references as Andriy K suggests.

Based on this post here you can simply download the Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package and the targets are installed.
This avoids the need to install Visual Studio on the build server.
I have just tried this out now, and can verify that it works:
Before:
error MSB4019: The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
After the install:
[Builds correctly]
This is a far better solution than installing Visual Studio on a build server, obviously.

The latest Windows SDK, as mentioned above, in addition to the "Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package" for Microsoft.WebApplication.targets and "Microsoft Visual Studio Team System 2008 Database Edition GDR R2" for Microsoft.Data.Schema.SqlTasks.targets should alleviate the need to install Visual Studio 2010. However, installing VS 2010 maybe actually be less overall to download and less work in the end.

Add dependency through NuGet & set a Build Parameter
Goal: no changes / installs necessary to the build agents
I have taken a hybrid approach to the NuGet approach by Lloyd here, which was based off of the committing binary dependencies solution by Andrik.
The reason why is I want to be able to add new build agents without having to pre-configure them with items such as this.
On a machine with Visual Studio, Open the solution; ignore that the web project fails.
In the NuGet package manager, add MSBuild.Microsoft.VisualStudio.Web.targets, as Lloyd mentioned.
This will resolve the binaries to [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
You can copy these to a references folder & commit,
Or just use them where they are at. I chose this, but I'm going to have to deal with the version number in the path later.
In Version 7, I did the following. This may not have been necessary, and based on the comments is definitely not needed now. Please see the comments below.
Next, in your TeamCity build configuration, add a build Paramenter for env.VSToolsPath and set it to the VSToolsPath folder; I used ..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath

When building on the build/CI server, turn off the import of Microsoft.WebApplication.targets altogether by specifying /p:VSToolsPath=''. This will, essentially, make the condition of the following line false:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
This is how it's done in TeamCity:

If you migrate Visual Studio 2012 to 2013, then open *.csproj project file with edior.
and check 'Project' tag's ToolsVersion element.
Change its value from 4.0 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
Solution Source

It seems the new version of msbuild does not ship with Microsoft.WebApplication.targets. To fix you need to update your csproj file as so:
1) Edit the web app csproj (right click). Find the section in the csproj towards the bottom concerning build tools. It should look like so.
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
2) You need to add one VSToolsPath line below the VisualStudioVersion tag so it looks like so
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<!--Add the below line to fix the project loading in VS 2017 -->
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<!--End -->
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
Reference link:
https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/

This is all you need. Only 103MB. Don't install everything

I have found this on MS connect:
Yes, you need to install Visual Studio
2010 on your build machine to build
database projects. Doing so does
not require an additional license of
Visual Studio.
So, this is the only option that I have for now.

Anyone coming here for Visual Studio 2017. I had the similar issue and couldn't compile the project after update to 15.6.1.
I had to install MSBulild tools but still the error was there.
I was able to fix the issue by copying the v14.0 folder from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio to the same folder as v15.0 and that resolved all the errors.
So now my folder structure looks like below, where both folders contain the same content.

If you are using MSBuild, as in the case of a build server, what worked for me is:
Change the following:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
to:
<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
My Msbuild command is: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*
Hope this helps someone.

My solution is a mix of several answers here.
I checked the build server, and Windows7/NET4.0 SDK was already installed, so I did find the path:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets`
However, on this line:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
$(MSBuildExtensionsPath) expands to C:\Program Files\MSBuild which does not have the path.
Therefore what I did was to create a symlink, using this command:
mklink /J "C:\Program Files\MSBuild\Microsoft\VisualStudio" "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio"
This way the $(MSBuildExtensionsPath) expands to a valid path, and no changes are needed in the app itself, only in the build server (perhaps one could create the symlink every build, to make sure this step is not lost and is "documented").

I fixed this by adding
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"
into
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments

I tried a bunch of solutions, but in the end this answer worked for me: https://stackoverflow.com/a/19826448/431522
It basically entails calling MSBuild from the MSBuild directory, instead of the Visual Studio directory.
I also added the MSBuild directory to my path, to make the scripts easier to code.

I was having this issue building a SQL Server project on a CI/CD pipeline. In fact, I was having it locally as well, and I did not manage to solve it.
What worked for me was using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from a set of SQL scripts, which implies creating a new project. But I wanted to keep the SQL Server project, so that I could link it to the live database through SQL Server Object Explorer on Visual Studio. I took the following steps to have this up and running:
Kept my SQL Server project with the .sql database scripts.
Created a .NET Standard 2.0 class library project, making sure that the target framework was .NET Standard 2.0, as per the guidelines in the above link.
Set the contents of the .csproj as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="MSBuild.Sdk.SqlProj/1.0.0">
<PropertyGroup>
<SqlServerVersion>Sql140</SqlServerVersion>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
</Project>
I have chosen Sql140 as the SQL Server version because I am using SQL Server 2019. Check this answer to find out the mapping to the version you are using.
Ignore the SQL Server project on build, so that it stops breaking locally (it does build on Visual Studio, but it fails on VS Code).
Now we just have to make sure the .sql files are inside the SDK project when it is built. I achieved that with a simple powershell routine on the CI/CD pipeline that would copy the files from the SQL Server project to the SDK project:
Copy-Item -Path "Path.To.The.Database.Project\dbo\Tables\*"
-Destination (New-item -Name "dbo\Tables" -Type Directory -Path "Path.To.The.DatabaseSDK.Project\")
PS: The files have to be physically in the SDK project, either in the root or on some folder, so links to the .sdk files in the SQL Server project won't work. In theory, it should be possible to copy these files with a pre-build condition, but for some obscure reason, this was not working for me. I tried also to have the .sql files on the SDK project and link them to the SQL Server project, but that would easily break the link with the SQL Server Object Explorer, so I decided to drop this as well.

In case if you're trying to deploy a project using VSTS, then issue might be connected with checking "Hosted Windows Container" option instead of "Hosted VS2017"(or 18, etc.):

I fixed this by running the build in a docker container, specifically dotnet/framework/sdk. It includes the VS build tools.

Creating a new project and copying over the settings should probably provide the best guidance in what to do. This is what it looks like on mine
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

In my case, It was just a Port-Block.

After installation of MSBuild tools from Microsoft, define the MSBuild path in the environment variable, so that it can be run from any path.
Edit the .csproj file in any notepad editor such as notepad++, and comment the
Check for the following elements,
-->
Make sure you use import only once, choose whichever works.
Make sure you have the following folder exists on the drive, "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0" or whichever version is referenced by MSBuild target at "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets"
From the command prompt, run the following command, to check
C:>msbuild "C:\\DotnetCi.sln" /p:Configuration=Release /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false
choose /p switch as appropriate, refer to enter link description here
enter image description here

All Visual Studio 2013 builds are now failing

Every single project I open in Visual Studio 2013 is now all of a sudden giving me the following error:
EverySingleProject.csproj : error : The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format. C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets
This is in the file:
Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
Why is this failing?

You also get this error if you try and open a VS 2017 RC 'simplified' .NET Core csproj file in an earlier version of Visual Studio.
These new project files look like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.App" Version="1.0.1" />
</ItemGroup>
</Project>
(From: https://blogs.msdn.microsoft.com/dotnet/2016/12/12/updating-visual-studio-2017-rc-net-core-tooling-improvements/)
You'll need to use a recent version of VS 2017 to open them.

I've had this like 2 days ago.
This saved me.
Hope this helps.
EDIT:
Fortunately the solution is simple:
In Windows Explorer navigate to the project
Right Click on the .cproj file, select Properties, and un-check the "Read Only" checkbox
Open up the .cproj file in Notepad
On line 2 change xmlns="http://schemas.microsoft.com/developer/msbuild/2008" to
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" (notice
this only difference is we changed 2008 to 2003)
Save your changes
In Visual Studio right click on the (currently unavailable) project and select "Reload Project"
The project will now load normally and you can get on with your life

Turns out one of my files in the MSBuild folder got corrupted.
This file: Microsoft.Common.CurrentVersion.targets
And another one of the files needed had vanished into the aether.
This file: Microsoft.CSharp.CurrentVersion.targets
Neither of which were replaced, or fixed, during a repair and then a complete reinstall of Visual Studio.
I ended up copying the files across from another installation and now everything is back to normal.

Fixed it by adding:
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
in the .csproj file.

I had this as well. The project was probably (undocumented!) a VS 2017 project and I was using VS 2013.
What I did was:
Create a new VS 2013 web application project,
Copy and paste all the rest of the original project files into the new project folder,
Open the new project and include all the necessary original project files,
Mess about with references, etc for a while until all the compile errors disappear,
Run, test, tweak.
Really not ideal, but it was the quickest solution for a small demo project. Not sure how you'd go with a large solution. Maybe someone will build a converter sometime. Maybe Microsoft could do that. [Chuckles to self.]

Removing the corresponding *.csproj.user file helped for the same symptoms.

External VS2013 build error "error MSB4019: The imported project <path> was not found"

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?

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:

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.

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

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.

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)' != ''" />

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.

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

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

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.

I have Visual Studio 2013 installed. This worked for me:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' != ''">12.0</VisualStudioVersion>`
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
So I've changed the condition from == to != and the value from 10.0 to 12.0.

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.

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.

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.

Use the correct version of MSBuild. Set Environment Variable to:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
This will also work for VS 2019 projects
Previously we were setting it to C:\Windows\Microsoft.NET\Framework\v4.0.30319

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 etc.my 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.

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\

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.

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: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html

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.

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.

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> -->

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.

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.

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.

The OutputPath property is not set for this project

When I try to compile my project from x86 debug mode in Visual Studio 2008. I am getting this error. When I looked at the property group of the project that complained, I see output path is set.
Here is the property group section for that .csproj file
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<FileAlignment>4096</FileAlignment>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
Can any one shed the light on this?
NOTE: When I compiled this Debug and Any CPU it worked.
UPDATED: Error 1 The OutputPath property is not set for this project. Please check to make sure that you have specified a valid Configuration/Platform combination. Configuration='Debug' Platform='x86'

I had exact same error after adding a new configuration via ConfigurationManager in Visual Studio.
It turned out when the 'Production' configuration was added for the whole solution (and each project) the OutputPath element was not added to the .csproj files.
To fix, I went to the Build tab in project properties, changed OutputPath from \bin\Production\ to \bin\Production (deleted trailing \) and saved changes. This forced creation of the OutputPath element in the .csproj file and the project has built successfully.
Sounds like a glitch to me.

If you are using WiX look at this (there is a bug)
http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html
Sometimes new build configurations get added to the .wixproj file further down the file, that is, separated from their sibling config definitions by other unrelated XML elements.
Simply edit the .wixproj file so that all the <PropertyGroup> sections that define your build configs are adjacent to one another. (To edit the .wixproj in VS2013 right click on project in Solution Explorer, Unload project, right-click again->Edit YourProject.wixproj. Reload after editing the file.)

You can see this error in VS 2008 if you have a project in your solution that references an assembly that cannot be found. This could happen if the assembly comes from another project that is not part of your solution but should be. In this case simply adding the correct project to the solution will solve it.
Check the References section of each project in your solution. If any of them has a reference with an red x next to it, then it you have found your problem. That assembly reference cannot be found by the solution.
The error message is a bit confusing but I've seen this many times.

This happened to me because I had moved the following line close to the beginning of the .csproj file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"/>
It needs to be placed after the PropertyGroups that define your Configuration|Platform.

had this problem as output from Azure DevOps after setting to build the .csproj instead of the .sln in the Build Pipeline.
The solution for me:
Edit .csproj of the affected project, then copy your whole
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCpu' ">
Node, paste it, and then change the first line as followed:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|any cpu' ">
The reason is, that in my case the error said
Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='release' Platform='any cpu'.
Why Azure wants to use "any cpu" instead of the default "AnyCpu" is a mystery for me, but this hack works.

The error shown in visual studio for the project (Let's say A) does not have issues. When I looked at the output window for the build line by line for each project, I saw that it was complaining about another project (B) that had been referred as assembly in project A. Project B added into the solution. But it had not been referred in the project A as project reference instead as assembly reference from different location. That location contains the assembly which compiled for Platform AnyCpu. Then I removed the assembly reference from the project A and added project B as a reference. It started compiling.
Not sure though how this fix worked.

I encountered the same error but the problem turned out to be because I had created a new configuration in my solution that didn't exist in referenced assemblies from another solution.
This can be resolved by opening the related solution and adding the new configuration to it as well.
This post gave me the idea to check the referenced assemblies after I'd already confirmed that all projects within my solution had the correct configuration:
http://gabrielmagana.com/2010/04/solution-to-the-outputpath-property-is-not-set-for-this-project/

If you get this error only when you try to compile your project from commandline using MSBuild (like in my case) then the solution is to passing the outputpath manually to MSBuild with an argument like /p:OutputPath=MyFolder.

I had the same error, so I looked on project settings and there in "Build" section is "Build output path" option. And value was empty. So I filled in "bin\" value a error disappeared. It solved my problem.

I have:
Right-click on project with issue -> Unload Project
Right-click on project and choose Edit *.csproj
Copy-paste
the configuration from existing configuration which works with specific name and targeting platform (I had Release |
x64):
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
<Prefer32Bit>true</Prefer32Bit>
</PropertyGroup>
Right-click project -> Reload Project
Rebuild project/solution

I had the same problem after I have added new configurations and deleted the "debug" and "release" configs.
In my case I was using a cmd file to run the build and publish process, but the same error was thrown.
The solution for me:
In the csproj file the following:
<Configuration Condition=" '$(Configuration)' == '' ">Debug< /Configuration>
was setting the Configuration to "Debug" if I did not specify an explicit one. After changing the node value from "debug" to my custom configuration, it all worked smoothly. Hope this will also help whoever is reading this :)

Another crazy possibility:
If you follow a simple source control arrangement of putting Branch\Main, Main, and Release next to each other and you somehow end up adding an existing project from Main instead of Branch\Main (assuming your working solution is Branch\Main), you may see this error.
The solution is simple: reference the right project!

I encountered this problem when adding a project to a solution then referencing it from yet another project in the same solution-- got the yellow warning icon over the reference, notice that path was empty.
The solution was similar to what #Amzath suggested, my projects were being compiled with different Target Frameworks, eg. .NET 4.0 vs 4.5.

In my case the built address of my app was set to another computer that was turned off so i turned it on and restart VS and problem solved.

Another cause: you add a project reference from project A to project B in solution X. However, solution Y that already contains project A is now broken, until you also add project B to solution Y.

I had the same problem,
Just edit the .wixproj to have all of the
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... > elements to be side by side.
That solved my issue

The WiX project I was using was hard-set in the configuration manager for x64 across the board. When making the Custom Action project for the solution, it defaulted everything to x86 within the .csproj file. So I unloaded the project, edited it by changing all x86 to x64, saved, reloaded, and was good to go after that.
I don't understand why I had to do this. The configuration manager was set to build as x64, but just wouldn't get set in the csproj file :(

For me, the error wasn't caused by an obscure issue as seems to have been the case for others e.g. this answer. In my case, the error message was pretty spot on at describing what was wrong. It was saying that I was attempting to build for a specific build configuration & target platform, but I didn't have that combination of configuration/platform defined in my project properties file. So I explored two options:
Modify the project file to support the given target platform, as per this answer
Modify the target platform of the build to one of the existing supported configurations as per the project properties
Both worked in the sense that both made the issue go away. But the second one was the correct one for me. The problem I had was as follows:
In VS, I had a target platform of x86 and there was a PropertyGroup for this in the project file, so this was all working fine.
But when I tried to build from the command line, using MSBuild.exe the default target platform was "any cpu", unless explicitly specified as a command line argument.
So the fix in my case, since I wanted to target x86, was to explicitly tell MSBuild on the command line to build for the x86 platform, as per this answer.
To quote that answer:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe my.sln /t:build /p:Configuration=Release;Platform=x86
Notice the important part:
;Platform=x86

After trying all the other suggestions posted here, I discovered the solution for me was to remove the following section from the .csproj file:
<ItemGroup>
<Service Include="{808359B6-6B82-4DF5-91FF-3FCBEEBAD811}" />
</ItemGroup>
Apparently this service from the original project (unavailable on local machine) was halting the entire build process, even though it wasn't essential for compilation.

I got this problem after adding a new platform to my project. In my case .csproj file was under Perforce source control and was read-only. I checked it out but VS didn't catch the change until I restarted it.

I have had similar issue on a Xamarin Project. It is maybe rare case but in case anyone else is having the issue. my project structure was like below
xamarin.Android project had a reference from xamarin.android.library project.
I created a plugin using some code from android.library project.
Now here is the problem. if you add project reference or nuget installation on xamarin.android library project. You will get this error. Developers assume that code was inside Android.Library project and i must reference the new plugin on this project. NO!
you must add a reference on Main Android project. because plugin->library->main project output isnt produced.

Similar to Philip Atz, I had the following line at the top of my .csproj file.
<Import Project="$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.iOS.CSharp.targets" />
Moving it further down solved this problem for me.