48
naszych projektów w TFS zorganizowane w taki sposób:najlepsze praktyki Nuget i TFS
$\DefaultCollection\ProjectName\Source <-- source code goes here
$\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here
Teraz Nuget to na scenie, czy jest jakiś powód, aby zmienić nasze podejście i używać folderu Nuget za pakiety dla bibliotek DLL, które pochodzą z Projekty świadome NuGet? Ja opierając tego powodu
1) tworzy dwa miejsca trzeba szukać zależnościami 2) pozostawia otwartą nas do jednego dewelopera aktualizacją pakietu i łamiąc pewne uzależnienie
powiedział, że jeśli ktoś może zgłosić to dobry powód, aby zacząć używać NuGet w środowisku TFS, z przyjemnością przedstawię twoje pomysły mojemu zespołowi tak, jakby były moje własne (żart).
Nie trzeba przechowywać paczki od Nuget w kontroli wersji, zamiast przy użyciu 'NuGet.exe' zapełnić lokalną kopię FROM' packages.config' plików w ramach projektów: http: // blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html – Richard
Jak to działa w przypadku rozwiązań, które mają wiele projektów? Nasz główny ma dwie aplikacje internetowe, dwie aplikacje konsolowe i usługę. Zaletą podejścia opartego na bibliotece dll jest to, że wszystkie z nich działają albo kończą się niepowodzeniem. –
Zobacz link: uruchom 'nuget-exe' dla każdego' packages.config' z tym samym folderem repozytorium, zostaną pobrane tylko brakujące pakiety (może to być również etap wstępnej kompilacji na projekt). – Richard