我有一个由 127 个项目组成的 C# .NET Core Web 应用程序解决方案。
其中一些更小，构建速度更快（不到 3 秒），一些持续时间更长（超过 45 秒）。 不幸的是，其中一些持久的东西是在最后建造的，没有明显的原因。
例如，持续 45 秒的项目在 127 个项目中被构建为第 111 个，这会导致在构建最后一个项目（该项目依赖于较慢的项目）之前延迟 30 秒以上。
缓慢的项目仅对其他 17 个项目有直接/间接依赖，因此我想强制 VS2022 在这 17 个项目完成后立即开始构建它。
我正在运行 16 个并行构建，因此让一些核心忙于大型项目并让小型项目并行构建会很棒。
从VS的角度来看，建造第18个或第111个并不重要，但太晚开始该项目就意味着直接延长总建造时间。这同样适用于该解决方案中的其他较大项目。
所有这 127 个项目的构建时间总和除以并行度表明，如果没有由于过晚构建较大项目而导致的延迟，解决方案的总构建时间可能会缩短 40%。
那么是否有任何标志、设置技巧可以让我强制 VS 准备构建顺序，以便这些优先项目（及其依赖项）更快构建，而其余项目则以“随机”顺序尊重依赖项？
我尝试向该项目上的其他项目添加人工构建依赖项，以推迟其构建并使 VS 更快地选择慢速项目。
如果依赖关系过于严格，这个缓慢的项目会被构建为第 70 个项目，但其他项目正在等待这个项目，因此延迟仍然存在，并且 CPU 没有得到充分利用。 如果依赖关系不是那么严格，VS 会过早构建较小的项目，从而导致延迟。
即使手动编辑解决方案文件并重新排序项目（不修改任何依赖项）也会对排序产生影响，并且上述项目在某些修改后构建为第 90 个，在其他修改后构建为第 103 个。但我找不到任何线索我对 sln 文件的编辑如何影响构建顺序。
您可以使用 MSBuild 命令行工具进行自定义构建并通过以下方式控制项目的构建顺序：
清洁解决方案：
msbuild YourSolution.sln /t:Clean
首先构建一个高优先级项目及其依赖项：
msbuild YourSolution.sln /t:ProjectA msbuild YourSolution.sln /t:ProjectB
构建项目的其余部分：
msbuild YourSolution.sln