我有以下场景：我有一个解决方案A，其中包含多个项目，包括一些“基本”项目和依赖于这些 base 项目生成的库的项目（由D表示）（因此D中的项目对 base 中的项目具有项目引用）。我也有两个解决方案过滤器：filter1.slnf包含 base 项目，filter2.slnf包含D中的项目。
首先运行msbuild filter1.slnf，然后运行msbuild filter.slnf /p:BuildProjectReferences=false。如果我理解正确的话，BuildProjectReferences=false是指示msbuild不要显式地构建项目引用/依赖项。目的是使第二个构建步骤利用来自前一个步骤的工件。对基本项目的更改很少，我不想在CI/CD管道中一次又一次地构建它们。但我也希望保留当前的解决方案，以便更容易进行那些不经常的更改，从而更容易进行解决方案过滤器。
在第二个命令的输出中，我看到msbuild正在尝试读取基本项目文件。
我的问题是，我应该在msbuild's open source-code中查看哪里来验证它是否只是简单地检查输出目录是否包含基本库？这种将完整解决方案的构建分解为不同构建的方法也是如此（例如一个过滤器用于基本项目，一个/或多个过滤器用于从属项目），使用解决方案过滤器可行（因为official blog似乎没有明确地说明这个用例）？
相关文章：How do you split a Visual Studio Solution?
1条答案
按热度按时间up9lanfz1#
对于格林菲尔德软件开发，我建议不要使用过滤器在同一管道中创建单独的构建。我还建议不要在同一管道中有单独的构建，不管构建是如何实现的。
鉴于以下情况：
我建议：
PackageReferenceGit非常高效，但是单独的repos仍然可以最小化构建所需的克隆大小。
不是在源代码控制中共享，而是通过包实现共享。通过对集合B使用包，现有构建本质上被保留并重新用于集合D的多个构建。
目前，NuGet和MSBuild无法在
PackageReference和ProjectReference之间交换或级联。有些情况下，这将是很好的，未来可能会有变化来解决这一问题。集合B和D可以在一个存储库中，但是应该存在没有共享源的单独目录，并且每个流水线中的CI触发器应该指定要包括和/或排除的路径。不应该有一个文件，如果改变，触发两个构建。