NuGet'ten sürüm denetimine paketleri mi ekliyorsunuz?


87

NuGet'ten önce, bir projede kullanılan tüm harici DLL'leri iade etmek yaygın olarak kabul edilen "en iyi uygulama" idi. Genellikle bir Libsveya 3rdPartydizininde.

NuGet ile çalışırken, packagesdizini iade etmem gerekiyor mu, yoksa MSBuild'in gerekli paketleri nuget feed'inden otomatik olarak indirmesinin bir yolu var mı?


2
Bunun cevabı bir fikir meselesi. "Hariç tut / Hayır" kampı, sağlanan özellik seti geliştirme ve oluşturma sırasında yalnızca paket havuzundan (örneğin nuget.org) çekmeyi kolaylaştırdığı için, yalnızca derleme zamanında yapılabileceğini savunur. "İnclude / Yes" kampı, harici deponun kullanılamaz hale gelmesi durumunda kodun paketler olmadan oluşturulmayacağını savunur. Karar vermeden önce her iki tarafı da okuyun. Ayrıca bakınız: softwareengineering.stackexchange.com/questions/301547/…
CJBS

Yanıtlar:


68

Hayır

Bu soru sorulduğundan, artık paketleri kaynak denetimine bağlamadan NuGet'i kullanmak için kolay bir iş akışı var

Paket yöneticisi konsolunuzdan 'NuGetPowerTools'u kurmanız gerekir :

Install-Package NuGetPowerTools

Ardından projelerinizin paket geri yüklemeyi desteklemesini sağlamak için başka bir komut çalıştırmanız gerekir:

Enable-PackageRestore

Artık kod tabanınızı paketler klasörü olmadan uygulamaya hazırsınız. Önceki komut proje dosyalarınızı değiştirdi, böylece paketler eksikse otomatik olarak indirilir ve eklenir.

Kaynak

NuGet'i paketleri kaynak denetimine taahhüt etmeden kullanma


41
NuGet-1.6'dan itibaren, bunu yapmak için artık NuGetPowerTools'a ihtiyacınız yoktur. Çözüm Gezgini'nde Çözüme sağ tıklayın ve Enable NuGet Package Restore. Dokümanlara bakın .
Kaleb Pederson

3
Evet, .nuget klasörünü ve altındaki dosyaları kontrol etmelisiniz.
absynce

11
@Edward - Felsefi olarak, bağımlılık oldukları göz önüne alındığında neden NuGet paketlerini kaynak denetimine dahil etmiyorsunuz? Kaynak kontrolünde kontrol edilen şey, bir derleme için yeterli kodun% 100'ü olmalıdır. NuGet paketlerini dahil etmeyerek, oluşturulan harici bağımlılıklar vardır, örn. ya paket indirme konumu değişirse ya da bazı garip nedenlerden dolayı artık mevcut değilse, vb. Ya da daha sonra pakette daha sonra yeniden indirilen ve derlemeyi bozan küçük bir değişiklik olursa ne olur? Projeyi inşa etmek için gereken her şey kaynak kontrolünde olsaydı, bundan kaçınılabilirdi.
Howiecamp

5
@Howiecamp Daha fazla katılamadım. Mantığı anlamıyorum. Kaynak kontrolünün tamamen bağımsız bir sistem olmasını istiyorum. Özellikle proje biraz mirassa ve bir süre erişilmezse. Geri dönüp hiçbir değişiklik yapmadan çalışmasını istiyorum. Nuget, sahip olmak istemediğim tek bir başarısızlık noktası.
Telavian

2
@Howiecamp Çözümümüz, kendi nuget sunucumuzu barındırmak ve tüm nuget paketlerini harici olarak GIT-LFS'ye yerleştirmektir. Bu, tek hata noktasını ortadan kaldırır ve her şeyi güzel bir şekilde sürüm kontrolü altında tutar. Ama yine de paketler klasörünü kontrol etmiyoruz - ve hala otomatik paket geri yüklemeyi kullanıyoruz
Casper Leon Nielsen

30

Evet. "Paketler" dizininin sorunuzda bahsettiğiniz "libs" dizininizle eşdeğer olduğunu düşünün. OSS projelerimde şahsen benimsediğim yaklaşım budur.

MSBuild'in gerekli paketleri otomatik olarak indirmesine izin verecek, ancak bu henüz uygulanmamış (NuGet 1.1'den itibaren) özellikleri araştırıyoruz.

Bazı kişilerin bu tür özellikleri zaten kendi başlarına uygulamış olabileceğini düşünüyorum, ancak planımız bu özelliğin NuGet 1.2 veya 1.3'te yerleşik olarak bulunmasına bakmaktır.


10
Bu özelliğin eklendiğini kesinlikle görmek isterim. Bir CI sunucusuna veya geliştirici PC'ye gerektiği gibi paketlerin indirilebilmesi güzel olurdu, böylece kaynak kontrol havuzunu üçüncü taraf DLL'lerle şişirmekten kaçınabilirsiniz.
John Mills

2
Visual Studio'daki paket yöneticisi ve komut satırı aracı, her ikisi de Paketleri "onarabilir" bu harika olurdu.
Shaun Wilson

1
Belki de artık bu yanıtı kaldırmak / düzenlemek iyi olur, artık kullanılmıyor
Lex

3
@Tim answer is not current imho
Edward Wilde

4
Bu cevap hala güncel. Global depoda olmayan paketleri düşünün (onları tamir etme / indirme yolu yoktur). IMHO, paketleri versiyonlama sisteminde saklamak iyi bir uygulamadır.
Pavel Hodek

6

Buradaki tüm yanıtlara rağmen, tüm bağımlılıklarınızın "bir tür" sürüm kontrolü altında olmaması hala basit ve korkunç bir çözümdür.

GIT için bu, GIT-LFS anlamına gelir.

NPM ile ilgili son bölüm bunun nedenini gösteriyor: Bağlı olduğunuz internet deposu kesintiye uğrarsa, kullanılamıyorsa vb., O zaman boka batmışsınız değil mi?

Artık kendi eşyalarınızı inşa edemezsiniz ve bu nedenle teslim edemezsiniz.


1
Bu çok iyi bir nokta. Kendi dahili NuGet sunucumuz olsa bile, derleme sırasında her zaman kullanılabilir olması için ona güvenebilir miyiz? Ayrıca, her derleme için her zaman yeni bir kopya almamız gerekecek şekilde paketlerimiz ne sıklıkla değişir?
Josh P

npmkırıldı çünkü paketleri listeden çıkarmadı, aslında onları sildi. NuGet bunu yapmaz; Herhangi bir noktada NuGet'e erişemezseniz, bir şeyler çok yanlıştır. Git'te bir bağımlılık yığını depolamanın iyi bir çözüm olduğunu düşünmüyorum: bağımlılıklarınızı belirli bir sürüme kilitleyin ve sizin için önemliyse, aranızda ve internette bir ayna bulundurun.
Dan

2
"NuGet bunu yapmaz". Peki hudiluhu, tamamen kontrolünüz dışında olan bir alanın geleceği için sözler verdiniz. Gerçek dünyada kontrol alanınızın dışındaki şeyler, aslında kontrol alanınızın dışındadır. Bu NuGet ve Npm için de geçerlidir. Dahası, sizin bir "ayna" fikriniz tam olarak burada önerdiğim şeydir, ancak dünyanızda "ayna" herhangi bir versiyon kontrollü şema tarafından desteklenmemektedir. Yine, yola çıktığınız sorunu çözmediniz.
Casper Leon Nielsen

5

Soruyu sorduğumdan beri, en sevilen Paketler dizinini kontrol etmek zorunda kalmamak için aşağıdaki yaklaşımı uyguladım .

Üst düzey bir build.msbuild dosyasında:

<Target Name="NuGet">
    <ItemGroup>
       <NuGetPackage Include="*\packages.config" />
    </ItemGroup>
    <Exec Command='libs\NuGet.exe install "%(NuGetPackage.FullPath)" -o Packages'  />

    <!-- optional for project that has JavaScript content -->
    <CreateItem Include="Packages\*\Content\Scripts\*">
       <Output TaskParameter="Include" ItemName="NuGetJSFiles"/>
    </CreateItem>
    <Copy SourceFiles="@(NuGetJSFiles)" DestinationFolder="MainProj\Scripts\" OverwriteReadOnlyFiles="true" SkipUnchngedFiles="true" />
    <Delete Files="MainProj\Scripts\.gitignore" />
    <WriteLinesToFile File="MainProj\Scripts\.gitignore" Lines="%(NuGetJSFiles.Filename)%(NuGetJSFiles.Extension)" /
    <Delete Files="@(PostNuGetFiles)" />
</Target>

Her project.csproj dosyasında

<Target Name="BeforeBuild">
    <Error Condition="!Exists('..\Packages\')" Text="You must run &gt; msbuild build.msbuild to download required NuGet
Packages" />

    <!-- optional for project that has JavaScript content -->
   <ReadLinesFromFile File="Scripts\.gitignore">
     <Output TaskParameter="Lines" ItemName="ReqJSFiles" />
   </ReadLinesFromFile>
   <Message Text="@(ReqJSFiles)" />
   <Error Condition="!Exists('Scripts\%(ReqJSFiles.Identity)')" Text="You must run &gt; msbuild build.msbuild to download required NuGet JS Package - Scripts\%(ReqJSFiles.Identity)" />
 </Target>

2
Bu işe yarıyor, ancak günümüzde en iyisi yerleşik etkinleştirme paketi geri yüklemesini kullanmak
Scott Weinstein

4

Bu soru ilk yayınlandığında ve yanıtlandığında gerçekliğin farklı olduğunu fark ettim, ama neyse ki cevap biraz değişti. Bir Pre-Build olayı kullanarak MSBuild aracılığıyla bağımlılıkları indirmek için NuGet kullanmak artık mümkün. Paketler klasörünü kod deponuza koymanıza gerek yoktur, tüm bağımlılıklar derleme sırasında indirilecek ve / veya güncellenecektir. Geçici bir çözüm olabilir, ancak yeterince iyi görünüyor. Ayrıntılar için şu blog gönderisine bakın: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html


4
Bunun derleme sunucusunun NuGet deposuna erişmesini gerektirdiğini hatırlayana kadar heyecanlandım ve bu, derleme sunucularının interneti göremediği yerde çalıştığım tek yer değildi.
Paket


3

Bu gönderi çok eski hale geldi. Cevap hala HAYIR, ancak çözüm değişti. NuGet 2.7+ sürümünden itibaren, NuGet.exe dosyasını kaynağınıza eklemeden otomatik paket geri yüklemeyi etkinleştirebilirsiniz (bu, en azını söylemek istenmeyen bir durumdur) ve herhangi bir modern DVCS kullanıyorsanız, paketler klasörünü göz ardı edebilirsiniz. Herhangi bir özel özelleştirmeye ihtiyacınız varsa, çözüm kökünde bir nuget.config dosyası oluşturabilirsiniz.

http://docs.nuget.org/docs/reference/package-restore

Ayrıca, yeni csproj formatıyla, artık entegre olduğundan ekstra nuget.config dosyalarından da kaçınabilirsiniz. Lütfen bunu daha iyi açıklayan bu gönderiye göz atın:

.Nuget klasörü sürüm kontrolüne eklenmeli mi?

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.