Jaki jest najlepszy sposób obsługi referencji w aplikacji .NET

Ostatnio w pracy natrafiliśmy na problem polegający na tym, że otagowaliśmy / rozgałęziliśmy projekt i mieliśmy pewne problemy z kompilacją z powodu odwołań dll / project, które wskazywały na starą strukturę folderów.

Utworzyliśmy folder „zewnętrznego pojemnika” dla każdego projektu i skopiowaliśmy dll do tych folderów. Czy to najlepszy sposób, czy istnieje jakiś konkretny standard branżowy, aby sobie z tym poradzić?

Powiedziałbym, że nuget jest najlepszym sposobem radzenia sobie z zależnościami.

nuget może zarządzać wersjami ORAZ automatycznie pobierać zależności z lokalnego serwera nuget.

Utworzenie / skonfigurowanie lokalnego serwera jest dość łatwe. Po prostu stwórz nowy pusty projekt ASP.NET i zainstaluj nuget-serverpakiet nuget (używając nuget;).

Oznacza to również, że nie będziesz musiał sprawdzać wszystkich zależności i / lub zarządzać ich wersjami za pomocą TFS.

To nie jest tak naprawdę - Microsoft twierdzi, że najlepszym sposobem na obsługę referencji jest zbudowanie projektu w jednym ogromnym rozwiązaniu. Tak, wiem, oni też naprawdę to mają na myśli.

Zespół wzorców i praktyk połączył swoje najlepsze praktyki w odniesieniu do TFS, ale dotyczy to ogólnych wersji. Istnieją 3 rodzaje konfiguracji rozwiązania, „1 duże rozwiązanie”, podejście podzielone na partycje, podobne do sposobu, w jaki większość ludzi używała zarządzania kompilacjami, budując kolejno i kopiując artefakty do wspólnego katalogu (co nie jest wspierane przez .NET nie posiadający ścieżkę „dołącz” lub „biblioteka” do całego serwera) oraz konfigurację wielu rozwiązań, która jest bardziej złożoną wersją partycjonowanej.

Mówią

In general you should:

    Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
    Use multiple solutions to create specific views on sub-systems of your application.
    Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.

W przypadku TFS zalecają rozgałęzienie wszelkich zewnętrznych projektów wewnątrz twojego projektu, zamiast polegać na mapowaniu obszaru roboczego, które jest bardziej podobne do zewnętrznych efektów subversion. Osobiście uważam, że ich porady nie są najlepszą praktyką, ale przypuszczam, że starają się zminimalizować wszelkie problemy z kompilacją, które wystąpią podczas korzystania z referencji.

Mam problemy z kompilacjami .NET, które próbują skrócić system, budując tylko to, co jest potrzebne, kompilacja nocna, która robi wszystko, a kopiowanie każdego nowego zestawu do katalogu było najlepszym sposobem dla wszystkich na synchronizację - szczególnie testerów. Zauważ, że to naprawdę dotyczy tylko aplikacji .NET, te w C ++ nadal działają, ponieważ nie mają zestawów wersji lub podobnych aspektów, które mogą powodować problemy z wywoływaniem komponentów. To podejście działa dobrze, ale nie zawsze można założyć, że częściowe kompilacje są w porządku, vaping całości i przebudowa jest najbezpieczniejsza.

Zależy to od struktury rozwiązania i możliwości oprogramowania do kontroli wersji. Wcześniej w naszych rozwiązaniach trzymaliśmy niezabudowany / pominięty projekt, w którym przechowywano dokumentację i folder specjalnie dla bibliotek, do których istnieją odniesienia stron trzecich. Ponieważ było to częścią rozwiązania, ścieżka do tych plików może być przywoływana przy użyciu ścieżki względnej. Po przejściu na TFS 2010 pozbyliśmy się tego projektu i po prostu dodaliśmy katalog „Wsparcie” w folderze tego rozwiązania w projekcie zespołu równolegle do naszych głównych gałęzi. W obu przypadkach wersja biblioteki kontroli źródła ostatecznie znajduje się w tym samym miejscu, niezależnie od tego, jak programiści skonfigurowali swoje maszyny.

Korzystając z subversion do kontroli wersji, można w tym celu wykorzystać właściwość „zewnętrzne” . Pozwala to zachować lokalną kopię współużytkowanej biblioteki DLL na ścieżce względnej w pobliżu bieżącego projektu. Ułatwia to odwoływanie się do tej biblioteki DLL za pomocą względnej ścieżki pliku, która się nie zmienia, nawet po zmianie głównego katalogu projektu na inny folder. Zewnętrzne pozwalają również określić, która konkretna wersja lub poprawka ma zostać uwzględniona.