从VS2010和MSBuild 4.0开始，VisualStudio和MSBuild似乎能够解析和构建不在解决方案中的项目引用。
让我们创建一个更具体的例子。使用名为 A 的C＃项目和名为 B 的另一个项目创建名为 Solution1 的解决方案。在项目B 中，添加对项目A 的引用。现在创建一个名为 Solution2 的新解决方案，然后单击“添加现有项目”并选择 Project B 。在解决方案资源管理器和警告列表中可以看到警告。
诀窍在于，即使“警告为错误”，我们也可以构建 Solution2.sln 。实际上，找到项目A 并由Visual Studio或MSBuild构建。让我们通过打开VS2010 / VS2012命令行来验证这一点并执行以下命令：
msbuild <dirPathToSolution1> Solution1.sln /t:clean **cleaning up solution1 with project A"
msbuild <dirPathToSolution1> Solution2.sln /t:build
ProjectA 是有效建立的，更糟糕的是：上面提到的警告甚至没有在那里提出。对于以前版本的Visual Studio，这种情况不可能发生（我已经使用msbuild 3.5和VS2008对其进行了测试）。
然而，在我们的情况下，我们希望防止这样的事情。实际上，我们有一个包含多个解决方案和许多提交者的大型源代码库。我们正在重新组织我们的依赖关系，最终旨在提取较小的存储库。同时，我们不希望开发人员在没有看到它的情况下添加隐藏的项目依赖项。我们希望只允许项目引用“内部”解决方案，将其他依赖项留给程序集引用。
所以问题是“有没有办法阻止像Solution2这样的解决方案来构建？”。理想情况下，它不应该与VS2012和MSBuild一起编译。但是，只有MSBuild命令行的解决方案才能归功于我们的连续集成。
答案 0 :(得分：1)
编辑我检查了Microsoft.Common.Targets，似乎没有任何方法可以实现您想要的效果。是否构建了项目引用，或者它们不构建（例如，这受到我原始答案的BuildProjectReferences标志的影响）。除非我遗漏了某些东西，否则无法选择性地构建它们，这主要是因为项目引用是在项目级别设置的，而不是在解决方案级别上：在项目文件中有一个MsBuild ItemGroup名为ProjectReferences并使用。 （实际上这是有道理的：如果你要求MsBuild构建projectB.csproj，并且B说它引用了A，那么没有解决方案可以发挥作用，你可以期望它构建一个A，毕竟你引用它了。）
现在据我了解，您希望禁止跨结构恰好由解决方案表示的目录进行引用。如果是这种情况，并且您真的需要这个，那么您可能会使用一个解析MsBuild日志并查找
之类的行的工具。Project "somedir\projectB.csproj" (2) is building "someOtherDir\projectA.csproj" (3) ...
然后从中提取目录信息，并使工具在不匹配时引发错误。然后将该工具合并到CI服务器中，并将其与msbuild日志文件一起提供。
原始回答
在命令行上尝试使用/p:BuildProjectReferences=false。顾名思义，它将禁用引用项目的构建。构建解决方案1时，这应该不是问题，因为无论如何都会在解决方案中构建projectA。但是，在构建solution2时，它不会构建projectA，您将收到构建错误。