Birden fazla çözümde atıfta bulunulan projelerle harici ve dahili paket kaynaklarında benzer bir durum var. Ben sadece bugün kod üslerinden biri ile çalışma var ve geliştirici iş istasyonları ve yapı sunucumuz ile çalışıyor gibi görünüyor. Aşağıdaki işlemde bu senaryo göz önünde bulundurulmaktadır (ancak ortak paketler klasörüne başka bir yere sahip olmak için uyum sağlamak zor olmamalıdır).
- Codebase
- Proje A
- Proje B
- Proje C
- Çözümler
- Çözüm 1
- Çözüm 2
- Çözüm 3
- Paketler (bu, tüm çözümlerin paylaştığı ortak pakettir)
NuGet 3.5.0.1484 sürümünden Visual Studio 2015 Güncelleştirme 3 ile güncelleştirilmiş yanıt
Bu süreç, bunu ilk başta ele aldığım zamandan biraz daha kolay ve bunu güncellemenin zamanının geldiğini düşündüm. Genel olarak, süreç sadece daha az adımla aynıdır. Sonuç, aşağıdakileri çözen veya sağlayan bir işlemdir:
- Kaynak kodu kontrolü için yapılması gereken her şey çözümde görülebilir ve izlenir
- Visual Studio'da Paket Yöneticisi'ni kullanarak yeni paketler yükleme veya paketleri güncelleme doğru havuz yolunu kullanır
- İlk yapılandırmadan sonra, .csproj dosyalarının saldırıya uğraması gerekmez
- Geliştirici iş istasyonunda değişiklik yok (Kod kullanıma hazır olarak hazırlandı)
Farkında olmak için bazı potansiyel dezavantajlar var (Henüz deneyimlemedim, YMMV). Bkz Benol en cevabını ve aşağıdaki yorumlar.
NuGet.Config Ekle
\ Solutions \ klasörünün kökünde bir NuGet.Config dosyası oluşturmak isteyeceksiniz. Bunun oluşturduğunuz UTF-8 kodlu bir dosya olduğundan emin olun, bunu nasıl yapacağınızdan emin değilseniz, Visual Studio'nun Dosya-> Yeni-> Dosya menüsünü kullanın ve ardından XML Dosyası şablonunu seçin. NuGet'e ekleyin.Aşağıdakileri yapılandırın:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="$\..\Packages" />
</config>
</configuration>
RepositoryPath ayarı için, $ belirtecini kullanarak mutlak bir yol veya göreceli yol (önerilen) belirleyebilirsiniz. $ Belirteci, NuGet.Config dosyasının bulunduğu yere dayanır ($ belirteci aslında NuGet.Config konumunun bir düzey altındadır ). Yani, \ Solutions \ NuGet.Config ve ben \ Solutions \ Packages varsa ben değer olarak $ \ .. \ Packages belirtmek gerekir.
Ardından, çözümünüze "NuGet" (Çözümünüze sağ tıklayın, Ekle-> Yeni Çözüm Klasörü) gibi bir çözüm olarak bir Çözüm Klasörü eklemek isteyeceksiniz. Çözüm Klasörleri, yalnızca Visual Studio çözümünde bulunan ve sürücüde gerçek bir klasör oluşturmayacak olan sanal klasörlerdir (ve her yerden dosyalara başvurabilirsiniz). "NuGet" çözüm klasörünüze sağ tıklayın ve ardından Ekle-> Mevcut Öğe'ye tıklayın ve \ Solutions \ NuGet.Config öğesini seçin.
Bunu yapmamızın nedeni, çözümde görünür olması ve kaynak kodu kontrolünüze uygun şekilde bağlı olduğundan emin olmanızda yardımcı olmasıdır. Kod tabanınızdaki paylaşılan projelerinize katılan her çözüm için bu adımı uygulamak isteyebilirsiniz.
NuGet.Config dosyasını .sln dosyalarının üzerindeki \ Solutions \ klasörüne yerleştirerek, NuGet'in klasör yapısını tekrar tekrar kullanacak bir NuGet.Config dosyası arayan "geçerli çalışma dizininden" yukarı doğru gezinmesi avantajından yararlanıyoruz. "Geçerli çalışma dizini" burada birkaç farklı şey anlamına gelir, biri NuGet.exe yürütme yolu ve diğeri .sln dosyasının konumu.
Paketler klasörünüzü değiştirme
İlk olarak, çözüm klasörlerinizin her birini gözden geçirmenizi ve var olan \ Packages \ klasörlerini silmenizi önemle tavsiye ederim (önce Visual Studio'yu kapatmanız gerekir). Bu, NuGet'in yeni yapılandırılmış \ Paketler \ klasörünüzü nereye yerleştirdiğini görmenizi kolaylaştırır ve yanlış \ Paketler \ klasörüne olan bağlantıların başarısız olmasını ve düzeltilmesini sağlar.
Çözümünüzü Visual Studio'da açın ve Tümünü Yeniden Oluştur'u başlatın. Alacağınız tüm derleme hatalarını yoksayın, bu noktada bu bekleniyor. Ancak bu, derleme işleminin başlangıcında NuGet paket geri yükleme özelliğini başlatmalıdır. \ Solutions \ Packages \ klasörünüzün istediğiniz yerde oluşturulduğunu doğrulayın. Yoksa, yapılandırmanızı gözden geçirin.
Şimdi, çözümünüzdeki her proje için şunları yapmak isteyeceksiniz:
- Projeye sağ tıklayın ve Projeyi Kaldır'ı seçin
- Projeye sağ tıklayın ve Düzenle-xxx.csproj dosyasını seçin
- \ Paketleri \ ile ilgili tüm referansları bulun ve yeni konuma güncelleyin.
- Bunların çoğu <HintPath> referansları olacaktır, ancak hepsi değil. Örneğin, WebGrease ve Microsoft.Bcl.Build'in güncellenmesi gereken ayrı yol ayarları olacaktır.
- .Csproj dosyasını kaydedin ve ardından projeye sağ tıklayın ve Projeyi Yeniden Yükle'yi seçin.
Tüm .csproj dosyalarınız güncellendiğinde, başka bir Yeniden Oluştur'u başlatın ve eksik referanslarla ilgili artık hata oluşturmamalısınız. Bu noktada işiniz bitti ve şimdi NuGet'in paylaşılan Paketler klasörünü kullanacak şekilde yapılandırılması sağlandı.
VStudio 2012 ile NuGet 2.7.1 (2.7.40906.75) itibarıyla
Unutulmaması gereken ilk şey, nuget.config dosyasının nuget paket sistemindeki tüm yol ayarlarını kontrol etmemesidir. Bunu anlamak özellikle kafa karıştırıcıydı. Özellikle, sorun msbuild ve Visual Studio'nun (msbuild çağrısı) nuget.config dosyasında yolu kullanmaması, bunun yerine nuget.targets dosyasında geçersiz kılmalarıdır.
Çevre Hazırlığı
İlk olarak, çözümünüzün klasörünü gözden geçirir ve var olan tüm \ Packages \ klasörlerini kaldırırdım. Bu, tüm paketlerin görünür bir şekilde doğru klasöre yüklendiğinden emin olmanıza ve çözümlerinizdeki bozuk yol referanslarını keşfetmenize yardımcı olacaktır. Ardından, en son nuget Visual Studio uzantısının yüklü olduğundan emin olurum. Ayrıca her çözümde en son nuget.exe yüklü olduğundan emin olun. Bir komut istemi açın ve her $ (SolutionDir) \ .nuget \ klasörüne gidin ve aşağıdaki komutu yürütün:
nuget update -self
NuGet için ortak paket klasör yolunu ayarlama
Her bir $ (SolutionDir) \ .nuget \ NuGet.Config dosyasını açın ve <configuration> bölümünün içine aşağıdakileri ekleyin:
<config>
<add key="repositorypath" value="$\..\..\..\Packages" />
</config>
Not: Mutlak bir yol veya göreceli bir yol kullanabilirsiniz. $İlegöreceli bir yol kullanıyorsanız, bununNuGet.Config konumunun bir düzey altında göreceli olduğunuunutmayın (bunun bir hata olduğuna inanıyoruz).
MSBuild ve Visual Studio için ortak paket klasör yolunu ayarlama
Her $ (SolutionDir) \ .nuget \ NuGet.targets dosyasını açın ve aşağıdaki bölümü değiştirin (Windows olmayanlar için altında başka bir bölüm olduğunu unutmayın):
<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
<!-- Windows specific commands -->
<NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
<PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
<PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>
Paketleri Güncelle
<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>
Not: GetFullPath, göreceli yolumuzu mutlak bir yola çözecektir.
Tüm nuget paketlerini ortak klasöre geri yükleme
Bir komut istemi açın ve her $ (SolutionDir) \ .nuget dosyasına gidin ve aşağıdaki komutu yürütün:
nuget restore ..\YourSolution.sln
Bu noktada, ortak konumunuzda tek bir \ paket \ klasörünüz bulunmalı ve çözüm klasörleriniz içinde hiçbiri bulunmamalıdır. Değilse, yollarınızı doğrulayın.
Proje referanslarını düzeltme
Her .csproj dosyasını bir metin düzenleyicide açın ve \ paketlerle ilgili başvuruları bulun ve doğru yola güncelleyin. Bunların çoğu <HintPath> referansları olacaktır, ancak hepsi değil. Örneğin, WebGrease ve Microsoft.Bcl.Build'in güncellenmesi gereken ayrı yol ayarları olacaktır.
Çözümünüzü oluşturun
Çözümünüzü Visual Studio'da açın ve bir yapıyı başlatın. Geri yüklenmesi gereken eksik paketlerden şikayet ederse, paketin eksik olduğunu ve geri yüklenmesi gerektiğini varsaymayın (hata yanıltıcı olabilir). .Csproj dosyalarınızdan birinde bozuk bir yol olabilir. Paketi geri yüklemeden önce bunu kontrol edin.
Eksik paketler hakkında derleme hatası var mı?
.Csproj dosyalarınızdaki yolların doğru olduğunu zaten doğruladıysanız, denemek için iki seçeneğiniz vardır. Bu, kodunuzu kaynak kodu kontrolünden güncellemenin sonucuysa, temiz bir kopyayı kontrol etmeyi ve ardından bunu oluşturmayı deneyebilirsiniz. Bu, geliştiricilerimizden biri için işe yaradı ve bence .suo dosyasında veya benzer bir şeyde bir eser var. Diğer seçenek, söz konusu çözümün .nuget klasöründeki komut satırını kullanarak bir paketi geri yüklemeyi zorlamaktır:
nuget restore ..\YourSolution.sln
$göreceli yolun önünde eksik olduğunuzu sanıyorum . Ayrıca, NuGet.Config dosyaları hakkındaki sorunuzun yanıtı burada . Bu .nuget ilk görünüyor, o zaman tüm üst dizinleri, sonra AppData içinde 'küresel' dosyasına: o zaman (ne olursa olsun TERS sırayla uygular olduğu anlamına gelir).