Wiele aplikacji w jednym rozwiązaniu Visual Studio [zamknięte]

Pracuję dla firmy, która chce połączyć wszystkie swoje aplikacje .Net (aplikacje internetowe, aplikacje Windows i aplikacje konsolowe) w jednym rozwiązaniu Visual Studio.

Szukam doświadczenia od programistów, którzy albo budują własne aplikacje w ten sposób, albo pracują w firmie, która to robi. Czy to dobry pomysł?

• Jakie są zalety / wady umieszczania wszystkich aplikacji w jednym rozwiązaniu zamiast posiadania osobnych rozwiązań dla każdej aplikacji?

• Jak szybko działa Visual Studio z rozwiązaniem ponad 20 projektów?

• A jak stabilny jest plik rozwiązania z jednoczesnym programowaniem kontrolowanym przez źródło?

Niedawno przenieśliśmy prawie cały kod źródłowy w mojej firmie do jednego rozwiązania.

Dlaczego?

Początkowo mieliśmy dziesiątki rozwiązań. Niektóre projekty z rozwiązania wykorzystywały ponownie projekty z innego i nikt nie dbał o użycie menedżera pakietów. W dniu, w którym znacząco zmienisz projekt, który jest używany prawie wszędzie, spodziewaj się godzin straconej pracy dla całej firmy na następne dni lub tygodnie. Najgorsze jest to, że nie możesz nawet wiedzieć, na co dokładnie miałaby wpływ zmiana.

Scalenie całego kodu w jedno rozwiązanie było alternatywą. Na razie działa dobrze, a zależności są teraz łatwe do naśladowania. Chcesz zmodyfikować metodę, ale także śledzić następstwa, jakie ta zmiana może mieć w dowolnym miejscu w bazie kodu? Visual Studio może to zrobić z łatwością. Dla mnie to sukces.

Ciągła integracja jest teraz również łatwiejsza. Jedno rozwiązanie do kompilacji i wdrożenia. Prawie nic do skonfigurowania.

Czy to jest skalowalne?

Pod względem wydajności byłem bardzo zaskoczony Visual Studio . Myślałem, że zacznie płakać z rozwiązaniem, powiedzmy, 50 projektami. Obecnie istnieje ponad 200 projektów; Visual Studio wydawało się być wystarczająco skalowalne, aby zarządzać nimi tak, jakby było ich tylko 20. Tak, są rzeczy, które wymagają czasu. Jeśli ponownie skompilujesz każdy projekt, z umowami Kod, domyślnie włączoną analizą kodu itp., Spodziewaj się, że zajmie to trochę czasu. Ale nikt nie spodziewałby się, że skompiluje 200 projektów tak szybko, jak 10, a swoją drogą nie powinieneś: taka jest rola serwera ciągłej integracji. Czas uruchamiania (zimny start, a następnie ładowanie rozwiązania) jest imponująco szybki ; może nie tak szybki jak w przypadku 10 projektów, ale wciąż bardzo akceptowalny (poniżej 20 sekund na maszynie kupionej ponad pięć lat temu).

Idąc dalej, systematyczne rozładowywanie projektów jest dobrym pomysłem (i naprawdę łatwe, gdy projekty są zorganizowane w katalogach w ramach rozwiązania). Jeśli ktoś pracuje nad czymś, co wymaga załadowania tylko trzech projektów, nie trzeba ładować wszystkich 200 projektów (chyba że oczywiście może to mieć wpływ na zależności).

Kontrola wersji działa również zgodnie z oczekiwaniami (używam serwera SVN, jeśli ma to znaczenie). Nie pracowałem w prawdziwym środowisku współbieżnym, powiedzmy, z dziesiątkami programistów często popełniających kod, ale wyobrażam sobie, że nie miałoby to zbyt wielu problemów. Uważaj tylko na przypadki, w których wielu programistów dodaje nowe projekty w tym samym czasie: scalenie pliku .sln nie jest najłatwiejsze.

Wniosek

Gdybym musiał ponownie wybrać decyzję:

1. Nadal migrowałbym wszystko do jednego rozwiązania. To ogromnie zmniejsza ból zerwanych zależności, a sama ta korzyść jest całkowicie tego warta. Dobrym pomysłem jest także scentralizowane miejsce na cały kod; umożliwia to na przykład wyszukiwanie czegoś w Visual Studio. Mogę także pracować nad dwoma słabo powiązanymi projektami i nadal mam otwarte tylko jedno okno Visual Studio.

2. Chciałbym również przestudiować nieco więcej NuGet i możliwość hostowania prywatnego serwera NuGet. Zarządzanie zależnościami za pomocą NuGet może rozwiązać niektóre problemy, gdy nie chcesz scalić kilku projektów w jedno wspólne rozwiązanie. Osobiście nie miałem takich przypadków, ale wyobrażam sobie, że inne firmy mogą to mieć.

3. Wreszcie, inwestycja w dysk SSD dla każdego programisty może mieć ogromną różnicę. Ale nie musisz, aw moim przypadku baza kodu jest nadal przechowywana na zwykłym dysku twardym.

To jest zamierzone użycie.

Jakie są zalety / wady umieszczania wszystkich aplikacji w jednym rozwiązaniu zamiast posiadania osobnych rozwiązań dla każdej aplikacji?

• plusy:
  • łatwiejsze odniesienia między projektami
  • łatwiejsze debugowanie / przechodzenie przez
  • łatwiejsze do dołączenia do procesów (np. przechodzisz przez usługę Windows, gdy przeskakuje ona do kodu biblioteki współużytkowanej, i działa po prostu, ponieważ wszystkie symbole są już załadowane i rozliczone)
  • wyszukiwanie kodu w ide działa lepiej (niekoniecznie musisz wiedzieć, w którym projekcie znajduje się kod, którego szukasz)
  • listy zmian między projektami są łatwiejsze w zarządzaniu (tj. zmieniłeś kod biblioteki, więc musisz zaktualizować kod klienta w tym samym czasie, z 1 zameldowaniem)
• Cons:
  • szybkość budowania: jeśli masz zwyczaj „odbudowywać wszystko”, to kompilacja trwa dłużej. Znacznie dłużej, a przyrostowe wersje czasem zachowują się funky.
  • ide prędkości: patrz dalej

Jak szybko działa Visual Studio z rozwiązaniem ponad 20 projektów?

Przy ponad 20 projektach ... może nie być tak źle. Widziałem więcej bez problemów VS. Jest dość stabilny / szybki. JEDNAK ... jeśli jest to problem, można go złagodzić: otwórz .csproj w VS i pracuj stamtąd. Nie zyskujesz korzyści z posiadania wszystkiego w jednym rozwiązaniu, ale zawsze możesz ponownie otworzyć SLN, kiedy potrzebujesz i pracować tylko w .csproj, kiedy potrzebujesz (tak jak teraz).

A jak stabilny jest plik rozwiązania z jednoczesnym programowaniem kontrolowanym przez źródło?

Plik rozwiązania zmienia się tylko podczas dodawania / usuwania projektów lub obiektów na poziomie rozwiązania, więc rzadko się zmienia. To jest xml, więc możesz zobaczyć, co jest w środku. Zmieniają się rzadko.