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ł:
- Kliknij projekt prawym przyciskiem myszy i wybierz opcję Zwolnij projekt
- Kliknij projekt prawym przyciskiem myszy i wybierz Edytuj your-xxx.csproj
- 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.
- 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
$przed względną ścieżką. Także odpowiedź na pytanie o plikach NuGet.Config jest tutaj . Najpierw szuka w .nuget, potem we wszystkich katalogach nadrzędnych, a następnie w pliku „globalnym” w AppData: następnie stosuje je w ODWRÓCONEJ kolejności (cokolwiek to znaczy).