Konfigurowanie wspólnego folderu pakietów NuGet dla wszystkich rozwiązań, gdy niektóre projekty są zawarte w wielu rozwiązaniach

Używam NuGet do pobierania pakietów z zewnętrznych i wewnętrznych źródeł pakietów, co jest bardzo wygodne. Ale zdałem sobie sprawę, że pakiety są domyślnie przechowywane według rozwiązania, co jest bardzo frustrujące, gdy niektóre projekty z odwołaniami do NuGet są zawarte w kilku rozwiązaniach. Następnie odniesienia są zmieniane na inny folder pakietu rozwiązań, który może być w rzeczywistości niedostępny dla innego programisty lub maszyny budującej.

Widziałem, że istnieją sposoby wskazania wspólnej lokalizacji pakietu (być może na poziomie głównym projektu, używamy kontroli źródła TFS) w wersji 2.1 programu NuGet, zobacz informacje o wersji . Używam NuGet v2.7

Ale próbowałem dodać pliki nuget.config bez żadnego efektu. Pakiety są nadal przechowywane w folderze rozwiązania. Czy jest coś, co przegapiłem? Wydaje się, że istnieją różne struktury węzła xml do dodania do pliku nuget.config, w zależności od tego, kto odpowiada na to pytanie: Schwarzie sugeruje w innym wątku Stackoverflow :

<settings>
  <repositoryPath>..\..\[relative or absolute path]</repositoryPath>
</settings>

Informacje o wersji dla NuGet 2.1 (zobacz link powyżej) sugerują ten format:

<configuration>
  <config>
    <add key="repositoryPath" value="..\..\[relative or absolute path]" />
  </config>
</configuration>

Nie wiem, który z nich, którykolwiek, lub oba będą działać w końcu. Próbowałem obu na poziomie rozwiązania. Czy plik nuget.config można umieścić na poziomie głównym projektu TFS, czy też musi znajdować się w katalogu rozwiązania? Wygląda na to, że NuGet odczytuje i stosuje ustawienia z tych plików w określonej kolejności, dlaczego warto byłoby dodać je na kilku poziomach, gdzie plik nuget.config na poziomie rozwiązania przesłaniałby jeden na poziomie głównym projektu TFS. Czy można to wyjaśnić?

Czy muszę usunąć wszystkie zainstalowane pakiety, zanim te odwołania będą działać? Bardzo chciałbym, gdyby ktoś mógł podać instrukcje krok po kroku dotyczące przechodzenia z użycia nuget dla konkretnego rozwiązania do wspólnego folderu pakietów, w którym projekty należące do kilku rozwiązań mogą znaleźć wymagane pakiety NuGet.

Mam podobną sytuację z zewnętrznymi i wewnętrznymi źródłami pakietów z projektami, do których odwołuje się więcej niż jedno rozwiązanie. Właśnie udało mi się to zrobić dzisiaj z jedną z naszych baz kodu i wydaje się, że działa ze stacjami roboczymi programistów i naszym serwerem kompilacji. Poniższy proces ma na uwadze ten scenariusz (chociaż nie powinno być trudno dostosować się do wspólnego folderu pakietów w innym miejscu).

• Codebase
  • Projekt A
  • Projekt B
  • Projekt C
  • Rozwiązania
    • Rozwiązanie 1
    • Rozwiązanie 2
    • Rozwiązanie 3
    • Pakiety (to jest wspólny dla wszystkich rozwiązań)

Zaktualizowana odpowiedź od NuGet 3.5.0.1484 z Visual Studio 2015 Update 3

Ten proces jest teraz nieco łatwiejszy niż wtedy, gdy początkowo zajmowałem się tym i pomyślałem, że nadszedł czas, aby to zaktualizować. Ogólnie proces jest taki sam, tylko z mniejszą liczbą kroków. Rezultatem jest proces, który rozwiązuje lub zapewnia:

• Wszystko, co należy zobowiązać do kontroli kodu źródłowego, jest widoczne i śledzone w rozwiązaniu
• Instalowanie nowych pakietów lub aktualizowanie pakietów przy użyciu Menedżera pakietów w programie Visual Studio spowoduje użycie poprawnej ścieżki repozytorium
• Po wstępnej konfiguracji nie wolno hakować plików .csproj
• Brak modyfikacji stacji roboczej programisty (kod jest gotowy do wyewidencjonowania)

Istnieją pewne potencjalne wady, o których należy pamiętać (jeszcze ich nie doświadczyłem, YMMV). Zobacz odpowiedź i komentarze Benola poniżej.

Dodaj NuGet.Config

Będziesz chciał utworzyć plik NuGet.Config w katalogu głównym folderu \ Solutions \. Upewnij się, że jest to plik zakodowany w formacie UTF-8, który tworzysz, jeśli nie masz pewności, jak to zrobić, użyj menu Plik-> Nowy-> Plik programu Visual Studio, a następnie wybierz szablon pliku XML. Dodaj do NuGet.Config następujące elementy:

<?xml version="1.0" encoding="utf-8"?>
<configuration>  
  <config>
    <add key="repositoryPath" value="$\..\Packages" />
  </config>
</configuration>

W przypadku ustawienia repositoryPath można określić ścieżkę bezwzględną lub ścieżkę względną (zalecane) przy użyciu tokenu $. Token $ jest oparty na lokalizacji NuGet.Config (token $ jest w rzeczywistości względem jednego poziomu poniżej lokalizacji NuGet.Config). Tak więc, jeśli mam \ Solutions \ NuGet.Config i chcę \ Solutions \ Packages, musiałbym określić $ \ .. \ Packages jako wartość.

Następnie będziesz chciał dodać folder rozwiązania do swojego rozwiązania o nazwie „NuGet” (kliknij rozwiązanie prawym przyciskiem myszy, Dodaj-> Nowy folder rozwiązania). Foldery rozwiązania to foldery wirtualne, które istnieją tylko w rozwiązaniu programu Visual Studio i nie utworzą rzeczywistego folderu na dysku (i możesz odwoływać się do plików z dowolnego miejsca). Kliknij prawym przyciskiem myszy folder rozwiązania „NuGet”, a następnie Dodaj-> istniejący element i wybierz \ Solutions \ NuGet.Config.

Powodem, dla którego to robimy, jest to, że jest on widoczny w rozwiązaniu i powinien pomóc w upewnieniu się, że jest odpowiednio przypisany do kontroli kodu źródłowego. Możesz chcieć wykonać ten krok dla każdego rozwiązania w Twojej bazie kodu, które uczestniczy w Twoich współdzielonych projektach.

Umieszczając plik NuGet.Config w katalogu \ Solutions \ nad jakimikolwiek plikami .sln, wykorzystujemy fakt, że program NuGet będzie rekurencyjnie nawigować po strukturze folderów w górę od „bieżącego katalogu roboczego” w poszukiwaniu pliku NuGet.Config do użycia. „Bieżący katalog roboczy” oznacza tutaj kilka różnych rzeczy, jedna to ścieżka wykonywania NuGet.exe, a druga to lokalizacja pliku .sln.

Przełączanie folderu pakietów

Po pierwsze, bardzo polecam przejrzenie każdego z folderów rozwiązań i usunięcie wszystkich istniejących folderów \ Packages \ (najpierw musisz zamknąć program Visual Studio). Ułatwia to sprawdzenie, gdzie NuGet umieszcza nowo skonfigurowany folder \ Packages \ i zapewnia, że ​​wszelkie linki do niewłaściwego folderu \ Packages \ nie powiodą się i można je naprawić.

Otwórz rozwiązanie w programie Visual Studio i rozpocznij Odbuduj wszystko. Zignoruj ​​wszystkie błędy kompilacji, które otrzymasz, jest to oczekiwane w tym momencie. Powinno to jednak spowodować uruchomienie funkcji przywracania pakietu NuGet na początku procesu kompilacji. Sprawdź, czy folder \ Solutions \ Packages \ został utworzony w wybranym miejscu. Jeśli tak nie jest, sprawdź swoją konfigurację.

Teraz dla każdego projektu w swoim rozwiązaniu będziesz chciał:

1. Kliknij projekt prawym przyciskiem myszy i wybierz opcję Zwolnij projekt
2. Kliknij projekt prawym przyciskiem myszy i wybierz Edytuj your-xxx.csproj
3. Znajdź wszelkie odniesienia do \ packages \ i zaktualizuj je do nowej lokalizacji.
   • Większość z nich to odwołania do <HintPath>, ale nie wszystkie. Na przykład WebGrease i Microsoft.Bcl.Build będą miały oddzielne ustawienia ścieżki, które będą wymagały aktualizacji.
4. Zapisz plik .csproj, a następnie kliknij projekt prawym przyciskiem myszy i wybierz opcję Wczytaj ponownie projekt

Po zaktualizowaniu wszystkich plików .csproj rozpocznij kolejny Odbuduj wszystko i nie powinieneś mieć więcej błędów kompilacji dotyczących brakujących odniesień. W tym momencie wszystko jest gotowe i masz teraz skonfigurowany pakiet NuGet do używania udostępnionego folderu Packages.

Począwszy od NuGet 2.7.1 (2.7.40906.75) z VStudio 2012

Po pierwsze, należy pamiętać, że plik nuget.config nie kontroluje wszystkich ustawień ścieżki w systemie pakietów NuGet. To było szczególnie mylące. W szczególności problem polega na tym, że programy MSBuild i Visual Studio (wywołując msbuild) nie używają ścieżki w pliku nuget.config, ale zamiast tego zastępują ją w pliku nuget.targets.

Przygotowanie środowiska

Najpierw przejrzałbym folder twojego rozwiązania i usunął wszystkie istniejące \ packages \ foldery. Pomoże to zapewnić, że wszystkie pakiety są w widoczny sposób instalowane we właściwym folderze i wykryć wszelkie odniesienia do złych ścieżek w rozwiązaniach. Następnie upewnię się, że masz zainstalowane najnowsze rozszerzenie NuGet programu Visual Studio. Chciałbym również upewnić się, że w każdym rozwiązaniu jest zainstalowany najnowszy plik NuGet.exe. Otwórz wiersz polecenia i przejdź do każdego folderu $ (SolutionDir) \ .nuget \ i wykonaj następujące polecenie:

nuget update -self

Ustawianie wspólnej ścieżki folderu pakietu dla NuGet

Otwórz każdy $ (SolutionDir) \ .nuget \ NuGet.Config i dodaj następujące elementy w sekcji <configuration>:

<config>
    <add key="repositorypath" value="$\..\..\..\Packages" />
</config>

Uwaga: możesz użyć ścieżki bezwzględnej lub ścieżki względnej. Pamiętaj, że jeśli używasz ścieżki względnej z $, to jest ona względna do jednego poziomu poniżej lokalizacji NuGet.Config (uważaj, że jest to błąd).

Ustawianie wspólnej ścieżki folderu pakietu dla MSBuild i Visual Studio

Otwórz każdy $ (SolutionDir) \ .nuget \ NuGet.targets i zmodyfikuj następującą sekcję (zwróć uwagę, że w przypadku systemów innych niż Windows jest pod nią kolejna sekcja):

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

Update PackagesDir to be

<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>

Uwaga: GetFullPath rozwiąże naszą ścieżkę względną na ścieżkę bezwzględną.

Przywracanie wszystkich pakietów NuGet do wspólnego folderu

Otwórz wiersz poleceń i przejdź do każdego $ (SolutionDir) \ .nuget i wykonaj następujące polecenie:

nuget restore ..\YourSolution.sln

W tym momencie powinieneś mieć pojedynczy folder \ packages \ we wspólnej lokalizacji i żaden z folderów rozwiązań. Jeśli nie, sprawdź swoje ścieżki.

Naprawianie odniesień do projektów

Otwórz każdy plik .csproj w edytorze tekstu i znajdź wszelkie odniesienia do \ packages i zaktualizuj je do właściwej ścieżki. Większość z nich to odwołania do <HintPath>, ale nie wszystkie. Na przykład WebGrease i Microsoft.Bcl.Build będą miały oddzielne ustawienia ścieżki, które będą wymagały aktualizacji.

Zbuduj swoje rozwiązanie

Otwórz swoje rozwiązanie w programie Visual Studio i rozpocznij kompilację. Jeśli narzeka na brakujące pakiety, które należy przywrócić, nie zakładaj, że brakuje pakietu i należy go przywrócić (błąd może wprowadzać w błąd). Może to być zła ścieżka w jednym z plików .csproj. Sprawdź to przed przywróceniem pakietu.

Masz błąd kompilacji dotyczący brakujących pakietów?

Jeśli już sprawdziłeś, że ścieżki w plikach .csproj są poprawne, masz dwie możliwości wypróbowania. Jeśli jest to wynikiem aktualizacji kodu z kontroli kodu źródłowego, możesz spróbować sprawdzić czystą kopię, a następnie ją zbudować. To zadziałało dla jednego z naszych programistów i myślę, że w pliku .suo był artefakt lub coś podobnego. Inną opcją jest ręczne wymuszenie przywrócenia pakietu za pomocą wiersza poleceń w folderze .nuget danego rozwiązania:

nuget restore ..\YourSolution.sln

Zamiast ustawiać wspólną lokalizację pakietu dla wszystkich projektów, można również zmienić HintPath w projekcie w następujący sposób:

<HintPath>$(SolutionDir)\packages\EntityFramework.6.1.0\lib\net40\EntityFramework.dll</HintPath>

W większości przypadków we współdzielonym projekcie będzie tylko kilka pakietów, więc możesz to łatwo zmienić.

Myślę, że jest lepszym rozwiązaniem, gdy rozgałęziasz kod, ustawiając wspólne repozytorium musisz zmienić ścieżkę względną, w tym rozwiązaniu nie musisz tego robić.

Moje doświadczenie, próbując tego z najnowszą wersją NuGet (2.7) i VS2012:

• Usuń folder .nuget (na dysku iw rozwiązaniu)
• Umieść plik NuGet.Config we wspólnym folderze nadrzędnym wszystkich rozwiązań
• Usuń wszystkie istniejące foldery pakietów
• Przejrzyj wszystkie pliki csproj i zmień HintPaths, aby wskazywały nową lokalizację
• Zysk

W moim przypadku chciałem umieścić wszystkie pakiety .packages, więc mój NuGet.Config wyglądał jak poniżej.

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <config>
     <add key="repositorypath" value=".packages" />
   </config>
 </configuration>

Zauważ, że może się zdarzyć kilka `` dziwnych '' rzeczy, ale myślę, że są one do zniesienia:

• Jeśli „zaktualizujesz” pakiet z jednego rozwiązania, natychmiast usunie on starszą wersję z folderu z pakietami (nie będzie wiedzieć, czy masz inne rozwiązanie, które tam wskazuje). Nie przeszkadza mi to zbytnio, ponieważ drugie rozwiązanie zostanie przywrócone w razie potrzeby.
• Jeśli spróbujesz dodać pakiet z rozwiązania klikniętego prawym przyciskiem myszy, jeśli pakiet jest już obecny w innym rozwiązaniu, zobaczy, że tam jest, i wyświetli „zielony znacznik” zamiast przycisku „zainstaluj”. Zwykle instaluję z kliknięciem prawym przyciskiem myszy na projekcie, więc wcale mi to nie przeszkadza.

Zastrzeżenie : właśnie wypróbowałem to dzisiaj, nie mam żadnego długoterminowego doświadczenia, aby to poprzeć!

Mam pakiet NuGet w wersji 2.8.50926 z VS 2013. Nie musisz używać wielu plików nuget.config ani używać złożonych struktur katalogów. Po prostu zmodyfikuj domyślny plik znajdujący się tutaj:

%APPDATA%\Roaming\NuGet\NuGet.Config

Oto zawartość mojego pliku:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\Projects\nugetpackages" />
  </config>
  <activePackageSource>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

Dlatego wszystkie pakiety trafiają do folderu „C: \ Projects \ nugetpackages”, bez względu na to, gdzie znajduje się rozwiązanie.

We wszystkich rozwiązaniach po prostu usuń istniejące foldery „pakietów”. Następnie skompiluj swoje rozwiązanie, a NuGet automatycznie przywróci brakujące pakiety w nowym, określonym przez Ciebie scentralizowanym katalogu.

Już nie ma potrzeby modyfikowania nuget.targets. Zostało to naprawione w nuget 2.8 ( http://nuget.codeplex.com/workitem/2921 ). Musisz tylko ustawić ścieżkę repozytorium.

Z wersji Visual Studio 2013 Update 4 i Nugget Package Manager> 2.8.5 ...

Utwórz plik nuget.config w katalogu głównym repozytorium.

zawartość pliku:

<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

Spowoduje to, że wszystkie pakiety trafią do folderu packages na poziomie twojego pliku nuget.config.

Teraz możesz przejść do każdej konsoli nuget .sln za pomocą polecenia „update-package -reinstall”

Jeśli masz wiele repozytoriów na tym samym poziomie i co chcesz udostępniać w tym samym folderze pakietów, spróbuj przejść o jeden folder w górę.

 <add key="repositoryPath" value="..\packages" />

Ale w ten sposób powodujesz, że pakiety nuget odwołują się do csproj, wskazując jeden folder poza ścieżką repozytorium.

Przygotowałem pakiet NuGet, który w sposób przejrzysty konwertuje wszystkie odwołania NuGet w projekcie na format względny $ (SolutionDir). Robi to za pomocą transformacji XSLT w czasie kompilacji, więc nie musisz ręcznie hakować pliku projektu. Możesz swobodnie aktualizować swoje pakiety, nic nie zepsuje.

https://www.nuget.org/packages/NugetRelativeRefs

Lub jeśli używasz programu Visual Studio 2015 Update 3, możesz po prostu zmigrować odwołania do pakietów do project.jsonformularza, jak opisano tutaj: https://oren.codes/2016/02/08/project-json-all-the-things

Aktualizowanie mojego doświadczenia z nuget 2.8.3. To było stosunkowo proste. Wszystko, co zrobiłem, było włączone przywracanie pakietów z rozwiązania prawym przyciskiem myszy. Edytowano NuGet.Config i dodano następujące wiersze:

  <config>
    <add key="repositorypath" value="..\Core\Packages" />
  </config>

Następnie przebudował rozwiązanie, pobrał wszystkie pakiety do wybranego folderu i automatycznie zaktualizował odniesienia. Zrobiłem to samo dla wszystkich moich innych projektów, w których pobierano tylko pakiety przyrostowe i odwoływałem się do istniejących pakietów. Stąd wspólne repozytorium pakietów dla wszystkich projektów.

Oto procedura krok po kroku, aby włączyć przywracanie pakietów.

http://blogs.4ward.it/enable-nuget-package-restore-in-visual-studio-and-tfs-2012-rc-to-building-windows-8-metro-apps/

Po prostu podłącz twarde łącze / pakiety do żądanej lokalizacji współdzielonej. Wtedy Twój projekt nie zostanie uszkodzony dla innych użytkowników, którzy nie mają specjalnej lokalizacji pakietów.

Otwórz wiersz polecenia jako administrator i użyj

mklink /prefix link_path Target_file/folder_path

W przypadku każdego znaczącego rozwiązania powyższe odpowiedzi będą niewystarczające. Po prostu złożona struktura obszaru roboczego TFS z różnymi ścieżkami względnymi, rozgałęzieniami, współdzielonymi projektami itp. Uniemożliwia utworzenie jednego centralnego repozytorium.

Używanie ($ SolutionDir) jest krokiem we właściwym kierunku, ale ręczne kodowanie pliku csproj za pomocą ($ SolutionDir) byłoby dość uciążliwe w bazie kodu z setkami pakietów, które są regularnie aktualizowane (za każdym razem, gdy następuje aktualizacja, HintPath jest nadpisywany przez nowa ścieżka względna). Co się stanie, jeśli musisz uruchomić Update-Package -Reinstall.

Istnieje świetne rozwiązanie o nazwie NugetReferenceHintPathRewrite . Automatyzuje wstrzykiwanie ($ SolutionDir) do HintPaths tuż przed kompilacją (bez faktycznej zmiany pliku csproj). Wyobrażam sobie, że można go łatwo włączyć do zautomatyzowanych systemów kompilacji

Krótkie podsumowanie dla użytkowników VS 2013 Professional z wersją NuGet : 2.8.60318.667

Oto jak skierowałbyś pakiety do ścieżki względnej do folderu .nuget:

<configuration>
  <config>
    <add key="repositoryPath" value="../Dependencies" />
  </config>
</configuration>

Na przykład, jeśli Twoje rozwiązanie (plik .sln) znajduje się w C: \ Projects \ MySolution, po włączeniu przywracania pakietu NuGet folder .nuget jest tworzony w następujący sposób: C: \ Projects \ MySolution.nuget i pakiety zostaną pobrane do katalogu takiego jak ten: C: \ Projects \ MySolution \ Dependencies

UWAGA: Z jakiegoś (nieznanego) powodu za każdym razem, gdy aktualizuję „ścieżkę repozytorium”, muszę zamknąć i ponownie otworzyć rozwiązanie, aby zmiany zaczęły obowiązywać

dla tych, którzy używają pakietu paket jako menedżera pakietów, istnieje opcja automatycznego dowiązania symbolicznego do pliku zależności:

storage: symlink

btw: paket wykorzystuje nuget

odniesienie: https://fsprojects.github.io/Paket/dependencies-file.html

Jeśli chcesz modyfikować jak najmniej, możesz po prostu okresowo czyścić podkatalogi za pomocą skryptu. to znaczy. Domyślnym zachowaniem NuGeta jest kopiowanie plików z lokalizacji globalnej do lokalnego folderu pakietów, więc usuń te pliki później.

Po prostu używam złączy NTFS, aby wszystkie foldery pakietów były kierowane bezpośrednio do pojedynczego folderu powyżej katalogu głównego repozytorium. Działa świetnie. Żadnych problemów z równoległym przywracaniem pakietów w wielu rozwiązaniach. Zaletą tego jest to, że nie musisz w ogóle rekonfigurować niczego w kodzie źródłowym, na przykład setek względnych ścieżek wskazówek w plikach .csproj. To „po prostu działa”, pozwalając systemowi plików obsłużyć przekierowanie i symulację pojedynczego folderu pakietów.

Po prostu uważaj na problemy „git”. Chociaż „stan git” w wierszu poleceń nie pokazuje żadnych zmian w fazie niestacjonarnej, zauważyłem, że GitKraken widzi połączenie „pakiet” jako plik niestacjonarny . Po kliknięciu wyświetla nawet błędy, takie jak „plik jest katalogiem”. GitKraken spróbuje również ukryć ten „plik”, jeśli dokonasz ponownej bazy danych, niszcząc połączenie i przywracając go jako rzeczywisty plik zawierający tekst z oryginalną ścieżką do pliku. Bardzo dziwne zachowanie. Może uda się to obejść, upewniając się, że plik pakietów został dodany do twojego .gitignore.

To są instrukcje z NuGet 2.1: http://docs.nuget.org/docs/release-notes/nuget-2.1

Nie ma potrzeby edytowania plików na poziomie rozwiązania.

Współpracuje z Visual Studio 2013 i trzema rozwiązaniami udostępniającymi projekty.

Nie zapomnij zaktualizować NuGet na poziomie rozwiązania (każdy plik NuGet.exe w folderach NuGet).