试图在构建服务器上构建我的项目给我以下错误:
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.
几个月前，我通过在Build Server上安装Visual Studio 2010解决了这个问题。但是现在我从头开始安装一个新的服务器，我想知道是否有更好的解决方案来解决这个问题。
根据这篇文章，你可以简单地下载Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package并安装目标。
这避免了在构建服务器上安装Visual Studio的需要。
我刚刚尝试了这一点，现在可以验证它的工作:
之前:
错误MSB4019:导入项目“C:\Program Files .
微软(x86) \ [\ \ VisualStudio \ v10.0 \ WebApplications \ Microsoft.WebApplication.targets”
没有找到。确认声明中的路径为
正确，并且该文件存在于磁盘上。
安装后:
(构建正确)
显然，这是比在构建服务器上安装Visual Studio更好的解决方案。
UPD:从VS2017开始，构建工具中的工作负载完全消除了这个问题。见@SOReader的答案。
如果您不希望在构建服务器上修改任何内容，并且仍然希望在源代码控制之外构建项目，那么将所需的二进制文件置于源代码控制之下可能是一个好主意。你需要修改项目文件中的imports部分，如下所示:
<Import Project="$(SolutionDir)\BuildTargets\WebApplications\Microsoft.WebApplication.targets" />
<Import Condition="false" Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
第一行是从相对于解决方案目录的新位置实际导入的。第二个是关闭的版本(Condition="false")，它允许Visual Studio仍然认为您的项目是一个有效的Web应用程序项目(这是VS 2010 SP1自己做的技巧)。
不要忘记将C:\Program Files (x86)\Microsoft\ VisualStudio\v10.0\WebApplications复制到源代码控制下的BuildTargets文件夹。
通过NuGet添加依赖项并设置一个构建参数
目标:对构建代理没有必要的更改/安装
我在这里采用了Lloyd的NuGet方法的混合方法，该方法基于Andrik的提交二进制依赖解决方案。
原因是我希望能够添加新的构建代理，而不需要使用诸如此类的项预先配置它们。
在机器上用Visual Studio打开解决方案;忽略web项目失败。
在NuGet包管理器中，添加MSBuild.Microsoft.VisualStudio.Web。目标，正如Lloyd提到的。
这将把二进制文件解析为[solution]\packages\ msbuild . microsoft . visualstudio . web .target .nn.n.n.n\tools\VSToolsPath\
你可以把这些复制到引用文件夹并提交，
或者就在它们所在的地方使用它们。我选择了这个，但是稍后我将不得不处理路径中的版本号。
在版本7中，我执行了以下操作。这可能是不必要的，根据评论，现在肯定不需要了。请看下面的评论。
接下来，在TeamCity构建配置中，为env添加一个构建参数。VSToolsPath并将其设置为VSToolsPath文件夹;我使用的是..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath
我的解决方案是这里几个答案的混合。
我检查了构建服务器，Windows7/NET4.0 SDK已经安装，所以我确实找到了路径:
C:\Program Files (x86)\MSBuild\Microsoft\ VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets
但是，在这一行:
<进口项目=”(MSBuildExtensionsPath美元)\ Microsoft \ VisualStudio v9 WebApplication 0 WebApplications \ Microsoft。很明显" - >
$(MSBuildExtensionsPath)扩展到C:\Program Files\MSBuild，其中没有路径。
因此，我所做的就是创建一个符号链接，使用下面的命令:
mklink /J "C:\Program Files\MSBuild\Microsoft\VisualStudio" "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio"
通过这种方式，$(MSBuildExtensionsPath)扩展到一个有效的路径，应用程序本身不需要更改，只需要在构建服务器中更改(也许可以在每个构建中创建符号链接，以确保这一步不会丢失并被“记录”)。
新版msbuild似乎没有附带Microsoft.WebApplication.targets。要修复你需要更新你的csproj文件，如下所示:
1)编辑web应用程序csproj(右键单击)。在csproj的底部找到关于构建工具的部分。应该是这样的。
<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)你需要在VisualStudioVersion标签下面添加一个VSToolsPath行，这样看起来就像这样
<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" />
参考链接:
https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/
解决方案是在构建服务器代理上安装可重新分发的包。它可以通过多种方式实现，下面将介绍其中3种方式。挑一个最适合你的。
使用UI安装程序
这是原来的答案
现在，在2017年，你可以用MSBuildTools安装WebApplication重定向。只需转到这个页面，下载MSBuild 2017工具，在安装时单击Web开发构建工具，即可安装这些目标:
这将导致默认情况下在C:\Program Files (x86)\Microsoft VisualStudio\ 2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications中安装缺失的库
使用命令行
免责声明:我没有测试过以下任何建议
正如@PaulHicks和@WaiHaLee在评论中建议的那样，它也可以从CLI以无头模式(没有ui)安装，这实际上可能是解决移除服务器问题的更好方法。
解决方案A -使用包管理器(choco)
choco install visualstudio2017-workload-webbuildtools
解决方案B -运行安装程序在无头模式
请注意，这是在原始答案中建议使用的相同安装程序
vs_BuildTools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools --passive
如果你正在使用MSBuild，就像在构建服务器的情况下一样，对我来说有用的是:
修改如下:
<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)' != ''" />
我的Msbuild命令是:*“C:\Program Files (x86)\ Msbuild \14.0\Bin\ Msbuild .exe”方案。sln /p:Configuration=Debug /p:Platform="任意CPU"* .
希望这能帮助到一些人。
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。/p:Configuration=Release /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false
根据需要选择/p开关，请参考此处输入链接说明
在这里输入图像描述
我在CI/CD管道上构建SQL Server项目时遇到了这个问题。事实上，我在当地也遇到过，但我没有设法解决它。
对我有效的是使用MSBuild SDK，它能够从一组SQL脚本生成SQL Server Data-Tier Application包(.dacpac)，这意味着创建一个新项目。但是我想保留SQL Server项目，这样我就可以通过Visual Studio上的SQL Server对象资源管理器将它链接到活动数据库。我采取了以下步骤让它运行起来:
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.
