2015-04-02 35 views
22

Już wcześniej szukałem rozwiązania, próbowałem różnych podejść, ale żadne nie działało, dlatego proszę tutaj.Submodules NuGet i Git

Obecnie potrzebuję mieć osobne repozytoria Git, z których każda zawiera plik rozwiązania .Net z powiązanymi projektami. Jeden lub więcej z tych repozytoriów będzie zawierało tylko biblioteki klas i muszę używać tych bibliotek w innych rozwiązaniach repozytoriów.

Po raz pierwszy użyłem modułów Git Submodules, aby uniknąć brzydkiej funkcji kopiowania i wklejania, a przy tworzeniu aplikacji nadal dostępny jest kod źródłowy biblioteki klas.

Tak więc moją próbą było włączenie modułu, a następnie w moim obecnym rozwiązaniu "dodaj istniejący projekt" i załaduj żądaną bibliotekę klas.

Ogromnym problemem, z którym nie mogłem sobie poradzić, jest przywracanie pakietów Nuget. Importowane projektów referencyjnych bibliotek w „.. \ Pakiety *”, ale gdy importowane jako modułem są zlokalizowane w dodatkowym podfolderze, więc nie mogą znaleźć wymagane zależności:

- MySolution.sln 
- Packages folder 
- MyAppProject folder 
- Submodule folder 
-- EXPECTED packages folder for MyLibraryProject that I cannot generate 
-- MyLibraryProject folder 

Jedno rozwiązanie znalazłem i próbowałem był this ale ma dwa główne problemy:

  • to ma pracować przy użyciu przywracania pakiet msbuild i absolutnie nie chcemy go używać
  • Nawet próbuje użyć pakietu MSBuild przywrócić go nie działa w ogóle, ja nadal mam pojedynczy folder Packages w moim bieżącym folderze rozwiązania. Może zrobiłem coś złego, ale znowu, nie chcę używać podejścia MsBuild.

Teraz Naprawdę chciałbym wiedzieć, czy to czysty sposób, aby rozwiązać ten problem, lub jeśli jedyne co mogę zrobić, to zrezygnować z posiadania kodu źródłowego biblioteki dostępny w moim rozwiązań aplikacyjnych i publikować moich bibliotek na prywatny kanał NuGet i odsyłaj go stamtąd.

Dzięki.

+1

Czy rozważałeś użycie NuGet dla MyLibraryProject zamiast submodułów git? Uruchom lokalny serwer NuGet, wygeneruj pakiet NuGet dla biblioteki i dodaj odniesienie do tej w swojej aplikacji. Po prostu opcja ... –

+0

Dziękuję za sugestię. Rzeczywiście rozważałem tę opcję, ale myślimy o korzystaniu z usługi online CI, takiej jak AppHarbor, która zmusiłaby nas do korzystania z publicznej (płatnej) usługi nuget, jak MyGet, aby móc przywrócić pakiety z Serwer CI, a chcielibyśmy tego uniknąć. –

+0

OK. I musisz mieć dwa poziomy katalogów dla projektu bibliotecznego? (Czy katalog modułów może być po prostu katalogiem bibliotecznym projektu?) –

Odpowiedz

5

Wygląda na to, że projekty z modułu częściowego znajdują się na innym poziomie katalogu niż ich rozwiązanie repo. Jest to częsty problem Nuget, ponieważ przywraca go na poziomie rozwiązania. Możesz użyć skryptu ścieżki podpowiedzi, aby zastąpić referencje $ (SolutionDir) i prawdopodobnie rozwiązać problem. https://github.com/owen2/AutomaticPackageRestoreMigrationScript/blob/master/README.md#fixhintpathsps1

+0

Widzę, że istnieje czysty skrypt programu Power Shell, który naprawia ścieżki wskazówek, aby móc je skryptować. Ocenię to możliwe rozwiązanie, dziękuję. –

+0

Czy to działa dla ciebie? – mshish

+0

Chociaż jest to rzeczywiście wykonalne, nadal jesteśmy w procesie podejmowania decyzji, chociaż wygląda na to, że będziemy używać Nuget do wewnętrznych zależności zamiast do submodułów git, jak sugerował @ jon-skeet. –