ChatGPT解决这个技术问题 Extra ChatGPT

Microsoft.WebApplication.targets was not found, on the build server. What's your solution?

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.

Are Web Application Projects deprecated? I wonder what the rationale is for requiring old versions of Visual Studio in order to build them?
More to the point, do you actually deploy via the build server? e.g. I don't, I even have a seperate web installer project in the solution... and it still wants this bloody thing... answer = remove it from the proj file! easy.
Fixed by replacing <Import Project="..\Packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" /> the path with $(VSToolsPath) as: <Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" />

C
Chris S

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.


This worked for m2 with a VS2012 project, after replacing v10.0 to v11.0
cant we just install MSBuild tools instead of this? microsoft.com/en-us/download/confirmation.aspx?id=40760
Alas, installing MSBuild tools is not enough to build projects that compile fine in VisualStudio 2013
I had to copy the Web folder to v11.0 to make it work after installing VS2013, it was missing there. Could compile in VS but not via MSBUILD directly.
worked for VS2017. just copy C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\vXX.0\WebApplications to C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications
S
SOReader

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

https://i.stack.imgur.com/LcxXq.png

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

I'm pretty surprised, that my five year old about packing libs into source control, and it modifications are still getting votes up even today, while this is correct out of the box answer.
@AndriyK Your solution is a bit different to what I suggested and I understand why somebody might prefer yours over mine... unless it's just laziness ;D
To make this more general, for future versions of Visual Studio, you can download the latest Build Tools from visualstudio.microsoft.com/downloads Scroll down the page and near the bottom expand the "Tools for Visual Studio" section, then download the "Build Tools for Visual Studio". Currently these are for VS 2017 but I assume it will be the same for future versions. By the way, if you need the path to msbuild.exe for your CI tool (eg Jenkins), for VS 2017 it will be installed at C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild.exe .
The build-server-compatible (read: command line) way of doing this is choco install visualstudio2017-workload-webbuildtools.
Also note that the "Web development build tools" package, Microsoft.VisualStudio.Workload.WebBuildTools, can be installed via the command line by calling vs_BuildTools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools. Add --passive to not need user intervention.
A
Abel

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.


Sayed - see below answer from dansomething - is your answer correct? Even installing the VS 2010 Shell Integrated package, and the .NET SDK will not correctly install Web Application project support?
@SayedIbrahimHashimi do you have to register the DLLs with the GAC if you do a manual folder copy?
And what about the Microsoft.TextTemplating.targets ? What do I have to do to get them in their folder? C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0
@ClarkKent, sorry I cannot speak to the TextTemplating file. I'm not familiar with those.
So I have to install IDE on my build server just to deploy? Microsoft is a joke right?
A
Andriy K

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.


This solution worked for me and was really the best option in my case. This is because I don't have access to the build server. I am using Atlassian's Elastic bamboo which spins up a new server to act as the build server. It doesn't appear at first glance that these AMIs include the Web Application targets?? That doesn't make sense to me but that is how it seems.
This is a good aproach, but this change requires each csproj file to be changed. It's tricky if you add new projects to solution. Of course it can be solved with custom project templates, but still.. Anyway, this answer pointed me to right direction. thanks!
K
Kobi

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.


It is impossible to use because I have to open the solution first but I cannot because of the error.
If there is more than one project in the solution, you should still be able to 1. open the solution - ignore that the web project doesn't load; 2. add the nuget reference; 3. take one of the approaches mentioned after that; you can manually edit the project file, or override the env.VSToolsPath variable in TeamCity.
is this an officially released MS nuget package, or did someone just create it?
wonderful solution - works for different versions of VS. I needed to edit the .csproj file, YMMV
It's not an officially released Microsoft nuget package. I know it because I created it.
M
Mark Lagendijk

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.


This is the easiest and simplest solution IMO. I am using VS 2013, and I found that the Visual Studio 2013 Shell (Isolated) Redistributable was what worked (the Integrated one wouldn't install due to dependency on the Isolated one).
@MatthewSkelton - What is the meaning of build server?
@BountyMan - a build server is a server that undertakes or controls Continuous Integration (CI) builds of the software. Examples: Jenkins, TeamCity, CruiseControl, etc.
Unfortunalely with VS v14.0, the way to install the package is through nuget but since my problem was that the build server did not have VS installed (only MSBuild), installing the package proved next to impossible. I spent hours fumbling with PowerShell and various half backed installation of Nuget before simply copying the folder from my PC to the server.
@pasx If the error message contains "v14" you can installed the Visual Studio 2015 Isolated Shell instead, worked for me - visualstudioextensibility.com/downloads/vs-shells (under "Download URLs"; there is a mandatory survey, enjoy!)
d
dansomething

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.


FYI - If you're trying to build Sql projects on a build server w/out installing full blown VS, you're out of luck with the Team System 2008 Database Edition GDR R2 installer mentioned here. It's pre-reqs are Visual Studio Team System 2008 Database Edition SP1 (English) or Visual Studio Team System 2008 Suite SP1 (English) AND Visual Studio 2008 Service Pack 1. It seems however you can copy SqlServer.targets out of .NET Framework\v4 directory and the TeamData msbuild targets files out of \program files\msbuild\microsoft\visual studio\v10.0\ and your csprojs will build.
It's definitely not the prettiest solution, but to me time is the most important. Simply copying over the MSBuild directory just lead to more issues for me.
This is a really important answer because if you are an independent developer setting up a build server for a client, you don't want the client to have to maintain a Visual Studio license to be able to build their software.
I only needed the VS2010 shell integrated package and EntLib 5 to get mine to build. Didn't need Team System.
The VS 2010 Shell is no longer available at that link, "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.".
D
Damon

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


no need to do step 4, if you simply replace the <Import> element in your project file with this one: <Import Project="..\..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.12.0.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" />
This should be the accepted answer... and point 4 should be deleted.
@Izzy thanks, did you do the comment as knocte indicated instead? I haven't used TC in a few years, version 7 iirc.
@Damon I'm using Jenkins and not TC, so that might be why I didn't need your last point.
A
Alex R.

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:

https://i.stack.imgur.com/7XSQE.png


Build targets are necessary if you're making use of Visual Studio's "Publish" mechanism. Doing this allows compilation to proceed and complete, but, it could be incomplete.
L
Luke

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

To

Or If you build with msbuild then just specify VisualStudioVersion property

msbuild /p:VisualStudioVersion=12.0

Solution Source


Adding /p:VisualStudioVersion=12.0 to MSBuild Arguments in the TFS 2013 build definition (for a solution created in Visual Studio 2013) worked for me. For some reason it would look for files in a v11.0 folder without any parameter.
This solution worked for me to, i used that command: msbuild /p:Platform=x86 /p:VisualStudioVersion=12.0
H
Huy Truong

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/


S
Simon_Weaver

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

https://i.stack.imgur.com/FEnvJ.png


How I am able to put in a checkmark on that form, without installing anything?
s
stacker

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.


The link seems to be broken.
H
Habib

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.

https://i.stack.imgur.com/BKRy0.png


A
Ali

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.


for to mention, the changes should be made to the offending .csproj, vbproj files.
K
Kat Lim Ruiz

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:

$(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").


M
MonoThreaded

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


C
Community

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.


c
ccoutinho

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: Sql140 netstandard2.0 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.


A
Arsen Khachaturyan

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.):

https://i.stack.imgur.com/PJNvj.png


P
Pankaj Awasthi

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

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


w
wilmol

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


b
broll

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

关注公众号,不定期副业成功案例分享
Follow WeChat

Success story sharing

Want to stay one step ahead of the latest teleworks?

Subscribe Now