14

在我们的团队中，开发人员都有 Visual Studio 2012，我们也使用 TFS2012 构建。出于空间和可管理性的原因，我们不在我们的（许多）构建代理上安装 Visual Studio。到目前为止，这适用于 C# 项目 (csproj)。

现在我们要添加对 C++ 项目 (vcxproj) 的支持。这些构建在开发者的机器上，而不是构建代理上——我们得到： X.vcxproj(31,3): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

我想这是因为 C++ 编译器和目标仅与 VS 一起安装。

  1. 有没有办法只检查编译器和目标，并在我们的 common.targets 中设置一些属性指向那里？
  2. 如果做不到这一点，我需要在每个构建代理上安装以支持 C++ 编译的最低要求是多少？我能找到的最少的是 VS Express，它仍然太合我的胃口。
4

2 回答 2

13

对于 C# 来说很简单，编译 C# 程序的能力在 System.CodeDom 框架中是天生的，所以只需安装 .NET 就足够了。对于 C++ 而言并非如此。您至少需要安装 Windows SDK，半场演出。这包括低于 8.0 的 SDK 版本中的 C++ 编译器

但是，您接下来会担心如何找到在该机器上获取类库的方法。例如 ATL 和 MFC。你不能只是复制它们，这违反了许可证。更糟糕的是，微软不再像过去那样做生意了。自 VS2012 以来，他们切换到快速发布周期，更新以几个月的方式发布。这些不是您可以忽略的更新，它们添加了相当大的块来实现 C++11。绝对是您的 C++ 程序员想要使用的那种。

一般来说，SDK 版本的 C++ 编译器只是与 VS 版本不同步，Windows 团队没有义务保持更新。构建机器永远不应该做的一件事是运行一组与程序员使用的构建工具不同的构建工具。这使得开发人员无法复制的构建中断成为一个令人讨厌的争论点。除非你喜欢让你的生活变得复杂，否则信息是明确的。不要这样做，安装VS。

于 2013-03-14T13:28:57.200 回答
0

早期 TFS 版本也存在此问题。据我所知，唯一的解决方案是将目标复制到代理。创建此文件夹的副本就足够了：

MSBuild\Microsoft\VisualStudio\v11.0\*.*

至少您不必在代理上安装 Visual Studio（除非您想自动创建安装项目）。

该错误也得到了描述here。

于 2013-03-14T13:17:19.713 回答