“Yerel Kopyala” ve proje referansları için en iyi uygulama hangisidir?

Ben büyük bir c # çözüm dosyası (~ 100 proje) var, ve inşa sürelerini iyileştirmeye çalışıyorum. "Yerel Kopyala" nın birçok durumda bizim için boşa harcadığını düşünüyorum, ancak en iyi uygulamaları merak ediyorum.

.Sln dosyamızda, C montajına bağlı olan B montajına bağlı olarak A uygulamamız var. Bizim durumumuzda düzinelerce "B" ve bir avuç "C" vardır. Bunların hepsi .sln'de yer aldığından proje referanslarını kullanıyoruz. Tüm derlemeler şu anda $ (SolutionDir) / Debug (veya Release) olarak oluşturulmuştur.

Varsayılan olarak, Visual Studio bu proje başvurularını "Yerel Kopyala" olarak işaretler, bu da her "C" nin oluşturulan her "B" için bir kez $ (SolutionDir) / Debug'a kopyalanmasıyla sonuçlanır. Bu savurgan görünüyor. "Yerel Kopyala" yı kapatırsam ne ters gidebilir? Büyük sistemlere sahip diğer insanlar ne yapar?

TAKİP ET:

Yanıtların birçoğu, yapıyı daha küçük .sln dosyalarına bölmeyi önerir ... Yukarıdaki örnekte, önce "C" temel sınıflarını, ardından "B" modüllerinin büyük kısmını ve daha sonra birkaç uygulamayı "derledim." bir". Bu modelde, B'den C'ye proje dışı referanslar almam gerekiyor. Orada karşılaştığım sorun "Hata Ayıkla" ya da "Serbest Bırakma" ipucu yolunda pişiriliyor ve "B" Serbest Bırakma yapılarımı kuruyorum. "C" hata ayıklama yapılarına karşı.

Derlemeyi birden çok .sln dosyasına bölenleriniz için bu sorunu nasıl yönetiyorsunuz?

Önceki bir projede, proje referanslarıyla birlikte büyük bir çözümle çalıştım ve bir performans sorunuyla da karşılaştım. Çözelti üç kat olmuştur:

1. Her zaman Yerel Kopyala özelliğini false olarak ayarlayın ve bunu özel bir msbuild adımı ile zorlayın

2. Her proje için çıkış dizinini aynı dizine ayarlayın (tercihen $ (SolutionDir) değerine göre)

3. Çerçeveyle birlikte gelen varsayılan cs hedefleri, o anda inşa edilen projenin çıktı dizinine kopyalanacak olan referans kümesini hesaplar. Bu, 'Referanslar' ilişkisi altında geçişli bir kapatmanın hesaplanmasını gerektirdiğinden, bu çok maliyetli olabilir. Bunun için geçici çözümüm, her bir projenin içe aktarılmasından sonra içe aktarılan GetCopyToOutputDirectoryItemsortak hedefler dosyasında (ör. Common.targets) Hedefi yeniden tanımlamaktı Microsoft.CSharp.targets. Sonuç olarak her proje dosyasında aşağıdaki gibi görünün:

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

Bu, belirli bir zamanda yapım süremizi birkaç saatten (çoğunlukla bellek kısıtlamaları nedeniyle) birkaç dakikaya indirdi.

Yeniden tanımlanmış GetCopyToOutputDirectoryItemsolan 2,438–2,450 ve 2,474–2,524 satırlarını C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targetsiçine kopyalayarak oluşturulabilir Common.targets.

Tamlık için, sonuçta elde edilen hedef tanım:

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

Bu geçici çözümle, tek bir çözümde 120'den fazla projeye sahip olmanın işe yaradığını gördüm, bu, projelerin derleme sırasının, çözümünüzü bölerek elle yapmak yerine VS tarafından belirlenebilmesinin ana avantajına sahiptir. .

Patric Smacchia'nın bu konudaki makalelerini okumanızı öneririm:

• Kod Tabanınızı .NET Meclisleri ve Visual Studio Projeleri ile Bölümleme -> Her Visual Studio projesi gerçekten kendi montajında ​​olmalı mı? Peki 'Yerel Kopyala = Doğru' ne demek?
• NUnit kod tabanından alınan dersler -> VisualStudio Project Reference + Yerel Kopyala gerçek seçeneği kötüdür! )
• CruiseControl.NET kod tabanının analizi -> Yerel Referans Kurulumu Kopyala seçeneğinin yanlış kullanımı True olarak ayarlanmış)

CC.Net VS projeleri, true olarak ayarlanmış kopya yerel başvuru derleme seçeneğine güvenir. [...] Sadece bu derleme süresini (NUnit durumunda x3) önemli ölçüde artırmakla kalmaz, aynı zamanda çalışma ortamınızı bozar. Sonuncusu ama aynı derecede önemli olarak, potansiyel problemlerin versiyonlanması riski ortaya çıkar. Btw, NDepend aynı adlı 2 farklı dizinde 2 derleme bulursa, ancak aynı içerik veya sürümde bir uyarı gönderir.

Yapılacak doğru şey 2 dizin $ RootDir $ \ bin \ Debug ve $ RootDir $ \ bin \ Release tanımlamak ve VisualStudio projelerinizi bu dizinlerde derlemeler yayınlayacak şekilde yapılandırmaktır. Tüm proje başvuruları, Debug dizinindeki derlemelere başvurmalıdır.

Bu makaleyi ayrıca proje numaranızı azaltmanıza ve derleme sürenizi geliştirmenize yardımcı olması için okuyabilirsiniz .

Bağımlılık ağacının üst kısmında yer alan hemen dışındaki tüm projeler için local = false kopyasını öneriyorum. Üst kümedeki tüm referanslar için local = true kopyalayın. Bir çıktı dizini paylaşmayı öneren birçok insan görüyorum; Bence bu deneyime dayanan korkunç bir fikir. Başlangıç ​​projeniz başka bir projenin size başvurduğu bir dll'ye başvuruyorsa, bir noktada local = false kopyala ve derlemeniz başarısız olsa bile bir noktada erişim \ paylaşım ihlali yaşayacaksınız. Bu sorun çok can sıkıcı ve izlenmesi zor. Ben tamamen bir shard çıkış dizininden uzak kalmak ve bağımlılık zincirinin üstündeki proje gerekli derlemeleri karşılık gelen klasöre yazmak yerine öneririz. "Üstte" bir projeniz yoksa, o zaman her şeyi doğru yerde almak için bir post-build kopyası öneririm. Ayrıca, hata ayıklama kolaylığı akılda tutulur. F5 hata ayıklama deneyiminin çalışması için kopya yerel = true bıraktığım tüm exe projeleri.

Haklısın. CopyLocal derleme sürelerinizi kesinlikle öldürecektir. Büyük bir kaynak ağacınız varsa, CopyLocal'ı devre dışı bırakmalısınız. Maalesef temiz bir şekilde devre dışı bırakmak kadar kolay değil. MSLUILD .NET .NET başvurularında CopyLocal (Private) ayarını nasıl geçersiz kılabilirim? Adlı CopyLocal devre dışı bırakma hakkında bu tam soruyu yanıtladı . Bunu kontrol et. Ayrıca Visual Studio'da (2008) büyük çözümler için en iyi uygulamalar.

İşte gördüğüm gibi CopyLocal hakkında daha fazla bilgi.

CopyLocal gerçekten yerel hata ayıklamayı desteklemek için uygulandı. Uygulamanızı paketleme ve dağıtım için hazırlarken, projelerinizi aynı çıktı klasörüne inşa etmeli ve ihtiyacınız olan tüm referanslara sahip olduğunuzdan emin olmalısınız.

MSBuild: Güvenilir Yapılar Oluşturmak İçin En İyi Uygulamalar, Bölüm 2 makalesinde büyük kaynak ağaçların nasıl oluşturulacağı hakkında yazdım .

Bence, 100 projeyle çözüm bulmak BÜYÜK bir hatadır. Çözümünüzü muhtemelen geçerli mantıksal küçük birimlere bölebilirsiniz, böylece hem bakımı hem de yapıları basitleştirebilirsiniz.

Kimsenin hardlink kullanarak bahsetmediğine şaşırdım. Dosyaları kopyalamak yerine, orijinal dosyaya bir bağlantı oluşturur. Bu, disk alanından tasarruf etmenin yanı sıra yapıyı büyük ölçüde hızlandırır. Bu, komut satırında aşağıdaki özelliklerle etkinleştirilebilir:

/ S: CreateHardLinksForAdditionalFilesIfPossible = true; CreateHardLinksForCopyAdditionalFilesIfPossible = gerçek; CreateHardLinksForCopyFilesToOutputDirectoryIfPossible doğru =; CreateHardLinksForCopyLocalIfPossible = true; CreateHardLinksForPublishFilesIfPossible = Gerçek

Tüm projelerinizin de bu avantajdan yararlanabilmesi için bunu merkezi bir içe aktarma dosyasına da ekleyebilirsiniz.

Eğer proje referansları veya çözüm seviyesi bağımlılıkları ile tanımlanmış bağımlılık yapınız varsa "Yerel Kopyala" yı çevirmek güvenlidir. Bunu yapmak için en iyi yöntem olduğunu söyleyebilirim. / maxcpucount aracılığıyla), başvurulan derlemeleri kopyalamaya çalışırken birbirinden farklı işlemler gerçekleştirmeden.

"en iyi uygulamamız" birçok projeyle çözümlerden kaçınmaktır. Derlemelerin güncel sürümlerini içeren "matrix" adlı bir dizinimiz var ve tüm referanslar bu dizinden. Bir projeyi değiştirirseniz ve "şimdi değişiklik tamamlandı" diyebilirseniz, derlemeyi "matris" dizinine kopyalayabilirsiniz. Dolayısıyla bu derlemeye bağlı tüm projelerin geçerli (= son) sürümü olacaktır.

Çözümde birkaç projeniz varsa, derleme işlemi çok daha hızlıdır.

Visual studio makrolarını kullanarak veya "menu -> tools -> harici araçlar ..." ile "montajı matris dizinine kopyala" adımını otomatikleştirebilirsiniz.

CopyLocal değerlerini değiştirmeniz gerekmez. Tek yapmanız gereken, çözümdeki tüm projeler için ortak bir $ (OutputPath) tanımlamak ve $ (UseCommonOutputDirectory) değerini true olarak ayarlamaktır. Bkz. Http://blogs.msdn.com/b/kirillosenkov/archive/2015/04/04/using-a-common-intermediate-and-output-directory-for-your-solution.aspx

Set CopyLocal = false derleme süresini azaltır, ancak dağıtım sırasında farklı sorunlara neden olabilir.

Yerel Kopyala 'yı Doğru olarak ayarlamanız gerektiğinde birçok senaryo vardır;

• Üst düzey projeler,
• İkinci seviye bağımlılıklar,
• Yansıma tarafından çağrılan DLL dosyaları

SO sorularında
" copy-local ne zaman true olarak ayarlanmalı ve ne zaman ayarlanmamalı? " Bölümünde açıklanan olası sorunlar ,
" Hata türü 'İstenen türlerden biri veya daha fazlası yüklenemedi. Daha fazla bilgi için LoaderExceptions özelliği alın.' "
Ve   Aaron-stainback 'ın cevabı  bu soru için.

CopyLocal = false ayarıyla ilgili deneyimim başarılı OLMADI. Benim blog yazısı bakınız “alt sekans anlamak sürece false olarak proje başvuruları." "Do DEĞİL Değiştir" Kopya yerel

Sorunları çözmek için gereken zaman, copyLocal = false ayarının faydalarını fazla kilolu.

Ben ortak bir dizin (örneğin .. \ bin) inşa etmek eğilimindedir, bu yüzden küçük test çözümleri oluşturabilirsiniz.

Projeler arasında paylaşılan tüm derlemelerin kopyalanacağı bir klasör kullanmayı deneyebilir, ardından bir DEVPATH ortam değişkeni oluşturabilir ve

<developmentMode developerInstallation="true" />

her geliştiricinin iş istasyonunda machine.config dosyasında ayarlayabilirsiniz . Yapmanız gereken tek şey, DEVPATH değişkeninin işaret ettiği klasörünüzdeki herhangi bir yeni sürümü kopyalamaktır.

Ayrıca çözümünüzü mümkünse birkaç küçük çözüme bölün.

Bu en iyi uygulama olmayabilir, ama ben böyle çalışıyorum.

Yönetilen C ++, tüm ikili dosyaları $ (SolutionDir) / 'DebugOrRelease' içine döker fark ettim. Bu yüzden tüm C # projelerimi de orada bıraktım. Çözümdeki projelere yapılan tüm referansların "Yerel Kopyala" özelliğini de kapattım. Küçük 10 proje çözümümde dikkate değer inşa süresi iyileştirmeleri yaptım. Bu çözüm, C #, yönetilen C ++, yerel C ++, C # webservice ve yükleyici projelerinin bir karışımıdır.

Belki bir şey bozulur, ama çalışmanın tek yolu bu olduğu için, fark etmiyorum.

Ne kırdığımı öğrenmek ilginç olurdu.

Genellikle, projenizi yalnızca başka bir yerde (GAC, diğer projeler vb.

Mümkünse bu çözümü kırmayı denemeniz gereken diğer insanlarla aynı fikirde olurum.

Ayrıca, yalnızca belirli proje kümelerini oluşturacak olan tek bir çözümde kendinizi farklı derleme yapılandırmaları yapmak için Configuration Manager'ı da kullanabilirsiniz.

100 projenin hepsi birbirine güveniyorsa tuhaf görünebilir, bu yüzden ya onu parçalayabilir ya da kendinize yardımcı olması için Configuration Manager'ı kullanabilirsiniz.

Sen dll hata ayıklama sürümlerini gösteren proje başvuruları olabilir. Msbuild betiğinize göre, /p:Configuration=Releaseuygulamanızın ve tüm uydu montajlarının yayın sürümüne sahip olacaksınız.

Yerel bir false kopyasını kullanarak bir DLL başvurmak için merkezi bir yer olmasını istiyorsanız, bunu yapmazsanız GAC olmadan başarısız olur.

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

Referans GAC içinde yer almıyorsa, uygulamanın çalışabilmesi için Yerel Kopyala'yı true değerine ayarlamalıyız, referansın GAC'ye önceden yükleneceğinden eminsek false olarak ayarlanabilir.

Peki, ben kesinlikle sorunların nasıl çalıştığını bilmiyorum, ama sembolik linkler yardımıyla bir ramdisk koymak tüm oluşturulan dosyaları kendisine yardımcı olan bir yapı çözümü ile temas vardı .

• c: \ çözüm klasörü \ bin -> ramdisk r: \ çözüm klasörü \ bin \

• c: \ çözüm klasörü \ obj -> ramdisk r: \ çözüm klasörü \ obj \

• Ayrıca, görsel stüdyoya derleme için hangi geçici dizini kullanabileceğini de söyleyebilirsiniz.

Aslında yaptığı her şey bu değildi. Ama gerçekten performans anlayışımı vurdu.
Tüm bağımlılıklarla% 100 işlemci kullanımı ve 3 Dakikadan küçük bir proje.