Cách thực hành tốt nhất cho Sao chép Sao chép cục bộ và với các tài liệu tham khảo dự án là gì?

Tôi có một tệp giải pháp c # lớn (~ 100 dự án) và tôi đang cố gắng cải thiện thời gian xây dựng. Tôi nghĩ rằng "Sao chép cục bộ" là lãng phí trong nhiều trường hợp đối với chúng tôi, nhưng tôi tự hỏi về các thực tiễn tốt nhất.

Trong .sln của chúng tôi, chúng tôi có ứng dụng A tùy thuộc vào cụm B phụ thuộc vào lắp ráp C. Trong trường hợp của chúng tôi, có hàng tá "B" và một số ít "C". Vì tất cả đều được bao gồm trong .sln, chúng tôi đang sử dụng các tham chiếu dự án. Tất cả các hội đồng hiện đang xây dựng thành $ (SolutionDir) / Gỡ lỗi (hoặc Phát hành).

Theo mặc định, Visual Studio đánh dấu các tham chiếu dự án này là "Sao chép cục bộ", dẫn đến mọi "C" được sao chép vào $ (SolutionDir) / Gỡ lỗi một lần cho mỗi "B" được xây dựng. Điều này có vẻ lãng phí. Điều gì có thể sai nếu tôi tắt "Sao chép cục bộ"? Những người khác với hệ thống lớn làm gì?

THEO SÁT:

Rất nhiều câu trả lời đề nghị chia nhỏ bản dựng thành các tệp .sln nhỏ hơn ... Trong ví dụ trên, tôi sẽ xây dựng các lớp nền tảng "C" trước, sau đó là phần lớn các mô-đun "B", sau đó là một vài ứng dụng, " Một ". Trong mô hình này, tôi cần có các tham chiếu phi dự án đến C từ B. Vấn đề tôi gặp phải là "Gỡ lỗi" hoặc "Phát hành" được đưa vào đường dẫn gợi ý và tôi kết thúc việc xây dựng các bản dựng "B" của mình. chống lại các bản dựng gỡ lỗi của "C".

Đối với những người chia phần xây dựng thành nhiều tệp .sln, làm thế nào để bạn quản lý vấn đề này?

Trong một dự án trước đây, tôi đã làm việc với một giải pháp lớn với các tài liệu tham khảo dự án và cũng gặp phải một vấn đề về hiệu suất. Giải pháp là ba lần:

1. Luôn đặt thuộc tính Sao chép cục bộ thành sai và thực thi điều này thông qua bước msbuild tùy chỉnh

2. Đặt thư mục đầu ra cho mỗi dự án vào cùng thư mục (tốt nhất là tương đối với $ (SolutionDir)

3. Các mục tiêu cs mặc định được phân phối với khung tính toán tập hợp các tham chiếu sẽ được sao chép vào thư mục đầu ra của dự án hiện đang được xây dựng. Vì việc này đòi hỏi phải tính toán đóng cửa bắc cầu theo quan hệ 'Tài liệu tham khảo', điều này có thể trở nên RẤT tốn kém. Cách giải quyết của tôi cho việc này là xác định lại GetCopyToOutputDirectoryItemsmục tiêu trong tệp mục tiêu chung (ví dụ Common.targets:) được nhập trong mọi dự án sau khi nhập Microsoft.CSharp.targets. Kết quả trong mỗi tệp dự án trông giống như sau:

   <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>
   

Điều này đã giảm thời gian xây dựng của chúng tôi tại một thời điểm nhất định từ vài giờ (chủ yếu là do hạn chế về bộ nhớ), xuống còn vài phút.

Định nghĩa lại GetCopyToOutputDirectoryItemscó thể được tạo bằng cách sao chép các dòng 2.438 Mạnh2,450 và 2,474 Mạnh2,524 từ C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targetsvào Common.targets.

Để hoàn thiện định nghĩa mục tiêu kết quả sau đó trở thành:

<!-- 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>

Với cách giải quyết này, tôi thấy có thể có tới 120 dự án trong một giải pháp, điều này có lợi ích chính là thứ tự xây dựng của các dự án vẫn có thể được xác định bởi VS thay vì thực hiện bằng cách chia nhỏ giải pháp của bạn .

Tôi sẽ đề nghị bạn đọc các bài viết của Patric Smacchia về chủ đề đó:

• Phân vùng cơ sở mã của bạn thông qua .NET Assemblies và Visual Studio Project -> Mỗi dự án Visual Studio có thực sự nằm trong hội đồng riêng của nó không? Và 'Copy Local = True' thực sự có nghĩa là gì?
• Bài học rút ra từ cơ sở mã NUnit -> Tham chiếu dự án VisualStudio + Sao chép tùy chọn đúng địa phương là xấu! )
• Phân tích cơ sở mã của CruiseControl.NET -> Việc sử dụng sai tùy chọn Sao chép hội nghị tham chiếu cục bộ được đặt thành True)

Các dự án CC.Net VS dựa trên tùy chọn lắp ráp tham chiếu cục bộ được đặt thành true. [...] Điều này không chỉ làm tăng đáng kể thời gian biên dịch (x3 trong trường hợp NUnit), mà còn làm rối tung môi trường làm việc của bạn. Cuối cùng nhưng không kém phần quan trọng, làm như vậy gây ra rủi ro cho phiên bản các vấn đề tiềm ẩn. Btw, NDepend sẽ phát ra cảnh báo nếu tìm thấy 2 hội đồng trong 2 thư mục khác nhau có cùng tên, nhưng không cùng nội dung hoặc phiên bản.

Điều đúng đắn cần làm là xác định 2 thư mục $ RootDir $ \ bin \ Debug và $ RootDir $ \ bin \ Release và định cấu hình các dự án VisualStudio của bạn để phát ra các cụm trong các thư mục này. Tất cả các tham chiếu dự án nên tham chiếu các cụm trong thư mục Debug.

Bạn cũng có thể đọc bài viết này để giúp bạn giảm số lượng dự án và cải thiện thời gian biên dịch.

Tôi đề nghị có sao chép local = false cho hầu hết tất cả các dự án ngoại trừ dự án nằm ở đầu cây phụ thuộc. Và đối với tất cả các tham chiếu trong một ở đầu bộ sao chép local = true. Tôi thấy nhiều người đề nghị chia sẻ một thư mục đầu ra; Tôi nghĩ rằng đây là một ý tưởng khủng khiếp dựa trên kinh nghiệm. Nếu dự án khởi động của bạn giữ các tham chiếu đến một dll rằng bất kỳ dự án nào khác có tham chiếu đến bạn, đôi khi bạn sẽ gặp phải vi phạm truy cập \ chia sẻ ngay cả khi sao chép local = false trên mọi thứ và bản dựng của bạn sẽ thất bại. Vấn đề này rất khó chịu và khó theo dõi. Tôi hoàn toàn khuyên bạn nên tránh xa thư mục đầu ra shard và thay vì để dự án ở đầu chuỗi phụ thuộc, hãy viết các cụm cần thiết vào thư mục tương ứng. Nếu bạn không có một dự án ở "đỉnh", sau đó tôi sẽ đề xuất một bản sao hậu xây dựng để có được mọi thứ ở đúng nơi. Ngoài ra, tôi sẽ cố gắng và ghi nhớ sự dễ dàng của việc gỡ lỗi. Bất kỳ dự án exe nào tôi vẫn để lại bản sao cục bộ = true để trải nghiệm gỡ lỗi F5 sẽ hoạt động.

Bạn nói đúng. CopyLocal sẽ hoàn toàn giết thời gian xây dựng của bạn. Nếu bạn có một cây nguồn lớn thì bạn nên tắt CopyLocal. Thật không may, nó không dễ dàng như vậy để vô hiệu hóa nó một cách sạch sẽ. Tôi đã trả lời câu hỏi chính xác này về việc vô hiệu hóa CopyLocal tại Làm cách nào để ghi đè cài đặt CopyLocal (Riêng tư) cho các tham chiếu trong .NET từ MSBUILD . Kiểm tra nó ra. Cũng như các thực tiễn tốt nhất cho các giải pháp lớn trong Visual Studio (2008).

Dưới đây là một số thông tin về CopyLocal như tôi thấy.

CopyLocal đã được triển khai thực sự để hỗ trợ gỡ lỗi cục bộ. Khi bạn chuẩn bị ứng dụng của mình để đóng gói và triển khai, bạn nên xây dựng các dự án của mình vào cùng một thư mục đầu ra và đảm bảo bạn có tất cả các tài liệu tham khảo bạn cần ở đó.

Tôi đã viết về cách đối phó với việc xây dựng các cây nguồn lớn trong bài viết MSBuild: Thực tiễn tốt nhất để tạo các bản dựng đáng tin cậy, Phần 2 .

Theo tôi, có một giải pháp với 100 dự án là một sai lầm LỚN. Bạn có thể có thể chia giải pháp của mình thành các đơn vị nhỏ logic hợp lệ, do đó đơn giản hóa cả bảo trì và xây dựng.

Tôi ngạc nhiên không ai đề cập đến bằng cách sử dụng liên kết cứng. Thay vì sao chép các tập tin, nó tạo ra một liên kết cứng đến tập tin gốc. Điều này giúp tiết kiệm không gian đĩa cũng như tăng tốc độ xây dựng. Điều này có thể được kích hoạt trên dòng lệnh với các thuộc tính sau:

/ p: CreateHardLinksForAdditableFiles IfPossible = true; CreateHardLinksForCopyAdditableFiles IfPossible = true;

Bạn cũng có thể thêm tệp này vào tệp nhập trung tâm để tất cả các dự án của bạn cũng có thể nhận được lợi ích này.

Nếu bạn có cấu trúc phụ thuộc được xác định thông qua tham chiếu dự án hoặc thông qua phụ thuộc cấp độ giải pháp, bạn có thể chuyển sang "Sao chép cục bộ", thậm chí tôi sẽ nói rằng đó là cách thực hành tốt nhất vì vậy sẽ cho phép bạn sử dụng MSBuild 3.5 để chạy song song bản dựng của bạn ( thông qua / maxcpucount) mà không có các quá trình khác nhau vấp ngã khi cố gắng sao chép các cụm được tham chiếu.

"thực hành tốt nhất" của chúng tôi là tránh các giải pháp với nhiều dự án. Chúng tôi có một thư mục có tên là "ma trận" với các phiên bản hiện tại của hội đồng và tất cả các tham chiếu đều từ thư mục này. Nếu bạn thay đổi một số dự án và bạn có thể nói "bây giờ thay đổi đã hoàn tất", bạn có thể sao chép tập hợp vào thư mục "ma trận". Vì vậy, tất cả các dự án phụ thuộc vào lắp ráp này sẽ có phiên bản hiện tại (= mới nhất).

Nếu bạn có một vài dự án trong giải pháp, quá trình xây dựng nhanh hơn nhiều.

Bạn có thể tự động hóa bước "sao chép cụm vào thư mục ma trận" bằng cách sử dụng macro phòng thu trực quan hoặc bằng "menu -> công cụ -> công cụ bên ngoài ...".

Bạn không cần thay đổi giá trị CopyLocal. Tất cả những gì bạn cần làm là xác định trước một $ chung (OutputPath) cho tất cả các dự án trong giải pháp và đặt trước $ (UseCommonOutputDirectory) thành đúng. Thấy điều này: http://blogs.msdn.com/b/kirillosenkov/archive/2015/04/04/using-a-common-intermediate-and-output-directory-for-your-solution.aspx

Đặt CopyLocal = false sẽ giảm thời gian xây dựng, nhưng có thể gây ra các sự cố khác nhau trong quá trình triển khai.

Có nhiều kịch bản, khi bạn cần phải sao chép Local 'sang True, vd

• Dự án cấp cao nhất,
• Phụ thuộc cấp hai,
• DLL được gọi bởi sự phản ánh

Các vấn đề có thể được mô tả trong các câu hỏi SO
" Khi nào nên sao chép cục bộ thành đúng và khi nào không nên? ",
"Thông báo lỗi 'Không thể tải một hoặc nhiều loại được yêu cầu. Truy xuất thuộc tính LoaderExceptions để biết thêm thông tin.' "
Và   câu trả lời của aaron-stainback  cho câu hỏi này.

Kinh nghiệm của tôi khi cài đặt CopyLocal = false là KHÔNG thành công. Xem bài đăng trên blog của tôi "KHÔNG thay đổi" Sao chép tham chiếu dự án Local cục bộ thành sai, trừ khi hiểu các phần tiếp theo. "

Thời gian để giải quyết các vấn đề thừa cân lợi ích của việc đặt copyLocal = false.

Tôi có xu hướng xây dựng vào một thư mục chung (ví dụ .. \ bin), vì vậy tôi có thể tạo các giải pháp thử nghiệm nhỏ.

Bạn có thể thử sử dụng một thư mục trong đó tất cả các tập hợp được chia sẻ giữa các dự án sẽ được sao chép, sau đó tạo biến môi trường DEVPATH và đặt

<developmentMode developerInstallation="true" />

trong tệp machine.config trên mỗi máy trạm của nhà phát triển. Điều duy nhất bạn cần làm là sao chép bất kỳ phiên bản mới nào trong thư mục của bạn, nơi DEVPATH biến điểm.

Cũng chia giải pháp của bạn thành một vài giải pháp nhỏ hơn nếu có thể.

Đây có thể không phải là năng lực tốt nhất, nhưng đây là cách tôi làm việc.

Tôi nhận thấy rằng Managed C ++ đã chuyển tất cả các nhị phân của nó thành $ (SolutionDir) / 'DebugOrRelease'. Vì vậy, tôi đã đổ tất cả các dự án C # của tôi ở đó quá. Tôi cũng đã tắt "Sao chép cục bộ" tất cả các tham chiếu đến các dự án trong giải pháp. Tôi đã cải thiện đáng kể thời gian xây dựng trong giải pháp dự án 10 nhỏ của mình. Giải pháp này là hỗn hợp của C #, C ++ được quản lý, C ++ gốc, C # webservice và các dự án cài đặt.

Có thể một cái gì đó bị hỏng, nhưng vì đây là cách duy nhất tôi làm việc, tôi không nhận thấy nó.

Sẽ rất thú vị khi tìm hiểu những gì tôi đang phá vỡ.

Thông thường, bạn chỉ cần Sao chép cục bộ nếu bạn muốn dự án của mình sử dụng DLL trong Bin so với những gì khác (GAC, các dự án khác, v.v.)

Tôi có xu hướng đồng ý với những người khác mà bạn cũng nên thử, nếu có thể, để phá vỡ giải pháp đó.

Bạn cũng có thể sử dụng Trình quản lý cấu hình để tạo cho mình các cấu hình xây dựng khác nhau trong một giải pháp sẽ chỉ xây dựng các bộ dự án nhất định.

Sẽ có vẻ kỳ quặc nếu tất cả 100 dự án dựa vào nhau, vì vậy bạn có thể phá vỡ nó hoặc sử dụng Trình quản lý cấu hình để tự giúp mình.

Bạn có thể có các tham chiếu dự án của bạn trỏ đến các phiên bản gỡ lỗi của các dll. Hơn trên tập lệnh msbuild của bạn, bạn có thể đặt /p:Configuration=Release, do đó bạn sẽ có phiên bản phát hành của ứng dụng và tất cả các cụm vệ tinh.

Nếu bạn muốn có một vị trí trung tâm để tham chiếu một DLL sử dụng bản sao sai cục bộ sẽ thất bại nếu không có GAC trừ khi bạn làm điều này.

http://nbaken.wordpress.com/2010/03/11/gac-alternative/

Nếu tham chiếu không có trong GAC, chúng ta phải đặt Copy Local thành true để ứng dụng hoạt động, nếu chúng ta chắc chắn rằng tham chiếu sẽ được cài đặt sẵn trong GAC thì nó có thể được đặt thành false.

Chà, tôi chắc chắn không biết các vấn đề đã được giải quyết như thế nào, nhưng tôi đã liên hệ với một giải pháp xây dựng giúp bản thân mình sao cho tất cả các tệp được tạo trên ramdisk với sự trợ giúp của các liên kết tượng trưng .

• c: \ thư mục giải pháp \ bin -> ramdisk r: \ thư mục giải pháp \ bin \

• c: \ thư mục giải pháp \ obj -> ramdisk r: \ thư mục giải pháp \ obj \

• Bạn cũng có thể nói thêm với studio hình ảnh mà thư mục temp có thể sử dụng để xây dựng.

Thật ra đó không phải là tất cả những gì nó đã làm. Nhưng nó thực sự đánh vào sự hiểu biết của tôi về hiệu suất.
Sử dụng bộ xử lý 100% và một dự án lớn trong vòng dưới 3 phút với tất cả các phụ thuộc.