Jak zatrzymać aktualizację Visual Studio przez aktualizację odniesień zespołu?

Question

W naszym środowisku mamy folder Lib zawierający różne podzespoły stron trzecich, do których odnoszą się nasze projekty. Na przykład Enterprise Libary i Elmah.

Czasami programista nie robi najnowszej wersji tego folderu. Gdy dev następnie załaduje projekt, który nie może znaleźć zespołu w oczekiwanym folderze, Visual Studio automatycznie znajdzie inną kopię i zaktualizuje odniesienia projektu.

Problem występuje, gdy programista sprawdza w projekcie i wkręca wszystkich w górę.

Czy istnieje sposób, aby zatrzymać to studio graficzne 2008?

AKTUALIZACJA: Chciałem dodać, że używamy TFS do kontroli źródła.

Answer 1

Oto, jak się przed tym bronimy w mojej firmie. (Twój przebieg będzie się zmieniać!)

każda niezgodność systemu (lub w inny sposób-GAC non) referencje pochodzą z naszego serwera dev, który każdy deweloper odwzorowanym na ich W: napędu. Mamy wspólny katalog DLL, z podkatalogami według klienta (lub dostawcy), a także, odpowiednio, dalszych podkatalogów. Żadne biblioteki DLL nie są przechowywane kiedykolwiek w kontroli kodu źródłowego, z wyjątkiem licencji.dll, zgodnie z potrzebami Infragistics sporadycznie.

Dla bibliotek dostarczonego przez producenta (EntLib, Infragistics, itd.), Jak polityka możemy odwoływać się od W: napęd. Kropka. Nikt nie jest upoważniony do odniesienia się nigdzie indziej. Koduje to podpowiedź w plikach projektu do wspólnej ścieżki.

uzyskać w domu biblioteki (klienta i projektów wewnętrznych), nasz ciągły proces integracji wyprowadza dll do odpowiedniego oddziału katalogu - znowu, gdzie wszystkie nasze referencje pochodzą z.

ten sposób spowolnić naszą lokalną czasu kompilacji (dla lokalnej debugowania), jak VS będzie automatycznie odświeżać je na serwer za każdym razem. To irytacja (czasami projekt może zająć 5 lub 6 minut, aby budować lokalnie), ale jest to zło konieczne do pracy z ludźmi używającymi różnych odniesień. Zaletą jest to, że gdy tylko ktoś sprawdzi kod dla jednego z tych odniesień, serwer CI uruchomi kompilację i każdy szybko ją zrobi.

Podstępem jest stabilny, powtarzalny proces kompilacji i ciągły serwer integracyjny. Używamy CruiseControl.NET, zintegrowanego z kompilacjami NAnt, ale wstaw tutaj swój ulubiony serwer CI i narzędzie do budowania.

Do tej pory w wyniku tego procesu nie wystąpiły żadne problemy, z wyjątkiem sytuacji, gdy serwer budowania uruchomi się, podczas gdy nasz system kontroli źródła (znany również jako Demon Spawn, zobacz tak wiele moich ostatnich uwag) wykonuje odprawa wielu plików. (Ponieważ Demon Spawn nie obsługuje transakcji kontrolnych). Jest to jednak bardzo rzadkie zdarzenie - być może raz na 5 lub 6 tygodni. Natychmiast po tym następuje przebudowa sił.

Tylko kilka myśli ... Ta technika powinna powstrzymywać ludzi przed zepsuciem kontroli nad źródłami - a jako dodatkowy bonus, zmniejszyć rozmiar kontroli źródła, ponieważ nie będziesz sprawdzać w bibliotekach DLL, po prostu dll.refresh akta.

Answer 2

Nie sądzę, że to możliwe.

Jeśli otworzysz plik projektu w edytorze tekstu, zobaczysz, że visual studio nie przechowuje twardych odniesień do zespołów, ale przechowuje „HintPath” zamiast. Jeśli referencja nie zostanie znaleziona, studio wizualne automatycznie wypróbuje GAC.

To może być dobry pomysł, aby założyć serwera ciągłej integracji (jeśli nie masz) to będzie działać jako system wczesnego ostrzegania o takich sytuacjach.

Answer 3

Zaangażowałem się z Johnem w większości punktów, z wyjątkiem umieszczania bibliotek dll w kontroli źródła.

Zazwyczaj mam folder ThirdParty, który będzie zawierał informacje o produktach i wersjach dostawców, więc zestaw narzędzi ajax jest przechowywany w $/ThirdParty/Microsoft/AjaxToolkit/(numer wersji). Podoba mi się to podejście, ponieważ możemy umieścić etykietę na wszystkich artefaktach, które idą do tworzenia.

Innym pomysłem może być dll w ramach projektu, więc jeśli otrzymają najnowszy projekt, otrzymają biblioteki DLL.

Answer 4

Tak, jest to ABSOLUTNIE WNĘTRZA i jest naprawdę bolesne. Oto inna opcja dla ciebie: 1. Usuń zeskładki z GAC, tak jak sugerują inne posty. 2. Niech system rozpoznawania zależności dostarcza zespoły do ​​folderu BIN. Tutaj też skompilowano by wszystkie zestawy rozwiązań. 3. Ustaw wszystkie odwołania Kopiuj lokalnie = false i Specific Version = False. Chodzi o to, aby podczas debugowania wystąpił wyjątek podczas ładowania złożenia, ponieważ jeśli nie znajduje się on w BIN, nie ma tam nic do skopiowania. I twoje rozwiązania będą kompilować się szybciej, ponieważ VS nie będzie musiał kopiować plików. A to uniemożliwi "nieumarłym" bibliotekom dll umieszczonym gdzieś w katalogu obj, który VS cudownie odnajdzie i skopiuje dookoła ...

To działa dobrze na rozwiązania, które kontrolujesz. Robimy to od lat. Bardzo łatwo jest ustalić, czy coś poszło nie tak, ponieważ po prostu szukasz zestawu z kopią Local = true lub Specific Version = True, co zdarza się raz na jakiś czas (zapomnij, zmęcz się itp.). Mój obecny problem polega na tym, że nie kontroluję struktury ani ustawień rozwiązania, nad którym pracuję, dlatego szukam rozwiązania dla tego starożytnego problemu. Miałem nadzieję, że zespół VS rozwiązał to ... Niestety ... Zespół, powstrzymaj ten ból.