問題描述
我有一個(gè)大型 c# 解決方案文件(約 100 個(gè)項(xiàng)目),我正在努力縮短構(gòu)建時(shí)間.我認(rèn)為復(fù)制本地"在很多情況下對(duì)我們來說是一種浪費(fèi),但我想知道最佳實(shí)踐.
I have a large c# solution file (~100 projects), and I am trying to improve build times. I think that "Copy Local" is wasteful in many cases for us, but I am wondering about best practices.
在我們的 .sln 中,應(yīng)用程序 A 依賴于程序集 B,而程序集 B 又依賴于程序集 C.在我們的例子中,有幾十個(gè)B"和少數(shù)C".由于這些都包含在 .sln 中,因此我們使用的是項(xiàng)目引用.當(dāng)前所有程序集都構(gòu)建到 $(SolutionDir)/Debug(或 Release)中.
In our .sln, we have application A depending on assembly B which depends on assembly C. In our case, there are dozens of "B" and a handful of "C". Since these are all included in the .sln, we're using project references. All assemblies currently build into $(SolutionDir)/Debug (or Release).
默認(rèn)情況下,Visual Studio 將這些項(xiàng)目引用標(biāo)記為復(fù)制本地",這會(huì)導(dǎo)致每個(gè)C"被復(fù)制到 $(SolutionDir)/Debug 中,對(duì)于每個(gè)構(gòu)建的B".這似乎很浪費(fèi).如果我只關(guān)閉復(fù)制本地"會(huì)出現(xiàn)什么問題?其他擁有大型系統(tǒng)的人是做什么的?
By default, Visual Studio marks these project references as "Copy Local", which results in every "C" being copied into $(SolutionDir)/Debug once for every "B" that builds. This seems wasteful. What can go wrong if I just turn "Copy Local" off? What do other people with large systems do?
跟進(jìn):
很多回復(fù)建議將構(gòu)建分解為更小的 .sln 文件...在上面的示例中,我將首先構(gòu)建基礎(chǔ)類C",然后是大部分模塊B",然后是一些應(yīng)用程序,A".在這個(gè)模型中,我需要從 B 獲得對(duì) C 的非項(xiàng)目引用.我遇到的問題是調(diào)試"或發(fā)布"被納入提示路徑,我最終構(gòu)建了B"的發(fā)布版本針對(duì)C"的調(diào)試版本.
Lots of responses suggest breaking up the build into smaller .sln files... In the example above, I would build the foundation classes "C" first, followed by the bulk of the modules "B", and then a few applications, "A". In this model, I need to have non-project references to C from B. The problem I run into there is that "Debug" or "Release" gets baked into the hint path and I wind up building my Release builds of "B" against debug builds of "C".
對(duì)于那些將構(gòu)建拆分為多個(gè) .sln 文件的人,您如何處理這個(gè)問題?
For those of you that split the build up into multiple .sln files, how do you manage this problem?
推薦答案
在之前的項(xiàng)目中,我使用了一個(gè)帶有項(xiàng)目引用的大型解決方案,但也遇到了性能問題.解決方案是三倍:
In a previous project I worked with one big solution with project references and bumped into a performance problem as well. The solution was three fold:
始終將 Copy Local 屬性設(shè)置為 false 并通過自定義 msbuild 步驟強(qiáng)制執(zhí)行此操作
Always set the Copy Local property to false and enforce this via a custom msbuild step
將每個(gè)項(xiàng)目的輸出目錄設(shè)置為同一個(gè)目錄(最好相對(duì)于$(SolutionDir)
Set the output directory for each project to the same directory (preferably relative to $(SolutionDir)
框架附帶的默認(rèn) cs 目標(biāo)計(jì)算要復(fù)制到當(dāng)前正在構(gòu)建的項(xiàng)目的輸出目錄的引用集.由于這需要在參考"關(guān)系下計(jì)算傳遞閉包,這可能會(huì)變得非常代價(jià)高昂.我的解決方法是在導(dǎo)入 Microsoft 后在每個(gè)項(xiàng)目中導(dǎo)入的通用目標(biāo)文件(例如
.導(dǎo)致每個(gè)項(xiàng)目文件如下所示:Common.targets
)中重新定義 GetCopyToOutputDirectoryItems
目標(biāo).CSharp.targets
The default cs targets that get shipped with the framework calculate the set of references to be copied to the output directory of the project currently being built. Since this requires calculating a transitive closure under the 'References' relation this can become VERY costly. My workaround for this was to redefine the GetCopyToOutputDirectoryItems
target in a common targets file (eg. Common.targets
) that's imported in every project after the import of the Microsoft.CSharp.targets
. Resulting in every project file to look like the following:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
... snip ...
</ItemGroup>
<Import Project="$(MSBuildBinPath)Microsoft.CSharp.targets" />
<Import Project="[relative path to Common.targets]" />
<!-- To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
</Project>
這將我們?cè)诮o定時(shí)間的構(gòu)建時(shí)間從幾個(gè)小時(shí)(主要是由于內(nèi)存限制)減少到了幾分鐘.
This reduced our build time at a given time from a couple of hours (mostly due to memory constraints), to a couple of minutes.
可以通過從 C:WINDOWSMicrosoft.NETFrameworkv2.0.50727Microsoft 復(fù)制第 2,438–2,450 和 2,474–2,524 行來創(chuàng)建重新定義的
變成 GetCopyToOutputDirectoryItems
.Common.targetsCommon.targets
.
The redefined GetCopyToOutputDirectoryItems
can be created by copying the lines 2,438–2,450 and 2,474–2,524 from C:WINDOWSMicrosoft.NETFrameworkv2.0.50727Microsoft.Common.targets
into Common.targets
.
為了完整起見,生成的目標(biāo)定義變?yōu)?
For completeness the resulting target definition then becomes:
<!-- This is a modified version of the Microsoft.Common.targets
version of this target it does not include transitively
referenced projects. Since this leads to enormous memory
consumption and is not needed since we use the single
output directory strategy.
============================================================
GetCopyToOutputDirectoryItems
Get all project items that may need to be transferred to the
output directory.
============================================================ -->
<Target
Name="GetCopyToOutputDirectoryItems"
Outputs="@(AllItemsFullPathWithTargetPath)"
DependsOnTargets="AssignTargetPaths;_SplitProjectReferencesByFileExistence">
<!-- Get items from this project last so that they will be copied last. -->
<CreateItem
Include="@(ContentWithTargetPath->'%(FullPath)')"
Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
>
<Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
<Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
<Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
</CreateItem>
<CreateItem
Include="@(_EmbeddedResourceWithTargetPath->'%(FullPath)')"
Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
>
<Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
<Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
<Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
</CreateItem>
<CreateItem
Include="@(Compile->'%(FullPath)')"
Condition="'%(Compile.CopyToOutputDirectory)'=='Always' or '%(Compile.CopyToOutputDirectory)'=='PreserveNewest'">
<Output TaskParameter="Include" ItemName="_CompileItemsToCopy"/>
</CreateItem>
<AssignTargetPath Files="@(_CompileItemsToCopy)" RootFolder="$(MSBuildProjectDirectory)">
<Output TaskParameter="AssignedFiles" ItemName="_CompileItemsToCopyWithTargetPath" />
</AssignTargetPath>
<CreateItem Include="@(_CompileItemsToCopyWithTargetPath)">
<Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
<Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
Condition="'%(_CompileItemsToCopyWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
<Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
Condition="'%(_CompileItemsToCopyWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
</CreateItem>
<CreateItem
Include="@(_NoneWithTargetPath->'%(FullPath)')"
Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_NoneWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
>
<Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
<Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
<Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
</CreateItem>
</Target>
有了這個(gè)解決方法,我發(fā)現(xiàn)在一個(gè)解決方案中擁有多達(dá) 120 個(gè)項(xiàng)目是可行的,這主要的好處是項(xiàng)目的構(gòu)建順序仍然可以由 VS 確定,而不是通過拆分手動(dòng)完成提出你的解決方案.
With this workaround in place I found it workable to have as much as > 120 projects in one solution, this has the main benefit that the build order of the projects can still be determined by VS instead of doing that by hand by splitting up your solution.
這篇關(guān)于“復(fù)制本地"的最佳做法是什么?和項(xiàng)目參考?的文章就介紹到這了,希望我們推薦的答案對(duì)大家有所幫助,也希望大家多多支持html5模板網(wǎng)!