Przenoszenie plików projektów w projekcie .NET

Question

Nie dotyczy to kodu, ale IDE. Pracuję nad rozwiązaniem .NET z około 35 różnymi projektami. Projekty te należy ponownie zorganizować w nową strukturę folderów. Czemu? Ponieważ około 10 z nich zostanie usuniętych, a reszta zostanie podzielona na bardziej logiczne jednostki. Jednym ze sposobów na to jest stworzenie nowego rozwiązania, Przeciągnij & Upuść projekty do nowego drzewa folderów w eksploratorze Windows, a następnie po prostu dodaj je do nowego rozwiązania. Szczerze mówiąc, to brzmi głupio!

Czy istnieje sposób przeniesienia projektów do różnych folderów z poziomu IDE? Próbowałem "zapisywać jako" projekty, ale IDE nie zaakceptuje innego folderu.

To irytujące, ale ponieważ w nazwach folderów pojawiło się kilka złych wyborów, utknąłem z tymi nazwami.

---

Przykład: W tej chwili mam główny folder projektu, który zawiera foldery podrzędne o nazwie "Klient", "Serwer", "Biznes", "Baza danych" i cokolwiek więcej. W tych folderach podrzędnych znajduje się więcej folderów podrzędnych, z których każda ma trzycyfrową liczbę. W każdym z numerowanych folderów znajduje się projekt nazwany w pewien logiczny sposób, np. Company.Business.Customers z dodatkową logiką w ramach tego projektu. Problem polega na tym, że nie wszystkie projekty są teraz zgodne z tą konwencją nazewnictwa i uważam ją za przestarzałą. Projekt taki jak Company.Business.Customers powinien po prostu znajdować się w folderze o nazwie Company.Business.Customers w katalogu głównym projektu, aby łatwiej go było rozpoznać. Nazwa już pokazuje, że jest to klasa biznesowa dla tego projektu. Wyraźny podział w obrębie klas klientów, klas biznesowych i tym podobnych rozwiązań musi być ułożony w ramach rozwiązania, ale chcę spłaszczyć strukturę plików. (I usuń niektóre przestarzałe projekty.) Zasadniczo, nie refactoring, po prostu sprzątam. VS2008 nie wydaje się mieć takiej opcji, chociaż ...

Answer 1

Użyłem następujące rozwiązanie, aby rozwiązać mój problem:

1. zacząłem z nowym, pustym roztworu w nowym folderze.
2. Dla każdego projektu, który musiał zostać przeniesiony, użyłem eksploratora Windows do utworzenia folderu podrzędnego w folderze rozwiązania, tym razem o właściwej nazwie.
3. Skopiowałem projekty z ich pierwotnej lokalizacji do ich nowych folderów.
4. Dodałem wszystkie (przeniesione) istniejące projekty z ich nowych lokalizacji.
5. W Menedżerze rozwiązań zmieniłem nazwę projektów na lepszą nazwę.
6. Poprawiłem właściwości projektu i inne ustawienia dla wszystkich projektów.

To całkiem posprzątało cały projekt.Następnie dodałem cały projekt do Vault (System kontroli wersji) i kiedy już znajdowałem się w VSS, usunąłem folder ponownie (właściwie, najpierw zmieniłem jego nazwę) i odzyskałem go z systemu VSS, więc wszelkie przestarzałe pliki binarne i inne śmieci były też zniknął. To dużo pracy, ale wynik okazał się dokładnie tym, czego potrzebował.

Answer 2

Nie sądzę, że istnieje łatwa odpowiedź tutaj. Twoim głównym problemem będzie to, że Visual Studio (lub .NET) nie obchodzi, czy masz klasy, które należą do innej przestrzeni nazw root znajdujących się w projekcie.

Więc jeśli masz projekt o nazwie Project.BusinessObjects i inny projekt o nazwie Project.DataObjects, nic nie stoi na przeszkodzie, aby umieścić klasę o nazwie Project.BusinessObjects.User w projekcie Project.DataObjects.

Nie znam żadnego sposobu na wykonanie tego wszystkiego bez ręcznej pracy. Resharper pomoże ci całkiem sporo, jeśli użyjesz funkcji "zmiany nazwy przestrzeni nazw", ale nadal będziesz musiał dużo pracować.

Answer 3

BARDZO nieufny wobec tego w połączeniu z systemami kontroli wersji. Musisz bardzo dobrze znać swój system kontroli wersji, aby wiedzieć, jak zareaguje na tak ważny proces refaktoryzacji.

Poza tym to, co opisujesz, nie jest wcale takie trudne. Musisz ręcznie edytować pliki rozwiązania, a może pliki projektu, i może być konieczne usunięcie projektu z rozwiązania i dodanie go ponownie, gdy znajduje się on pod odpowiednim katalogiem.

Zrobiłabym kopię zapasową, a następnie odfiltrował. Myślę, że błędem jest myślenie, że możesz zrobić wszystko, czego potrzebujesz od IDE. A jeśli zrobisz to, co opisujesz z IDE w systemie kontroli źródła, który używa starego interfejsu API Visual SourceSafe, to z pewnością (z pewnością) zepsujesz swoje powiązania, że ​​API nie jest po prostu stworzone do przenoszenia (lub zmiany nazwy, jeśli o to chodzi) pliki w sposób opisany przez Ciebie. Najlepszym sposobem wykonania tego w tym scenariuszu jest usunięcie wszystkich powiązań kontroli kodu źródłowego, a następnie ponowne dodanie ponownie zreorganizowanego rozwiązania.

To nie jest takie trudne, wystarczy przygotować (wykonać kopię zapasową) i eksperymentować, aż wszystko będzie w porządku.

Answer 4

Uruchomienie pliku notepad.exe i otwarcie pliku .sln. I uruchom Eksploratora Windows, przejdź do katalogu rozwiązań. Obserwuj, jak zawartość pliku .sln jest zgodna ze strukturą rozwiązania. Edytuj wpisy, wprowadź odpowiednią zmianę za pomocą Eksploratora. Najpierw wykonaj kopię zapasową.

Answer 5

Nie sądzę, że jest jakikolwiek sposób, aby to zrobić z Visual Studio, a jak @gmana wskazuje, że będzie to bardzo trudne, jeśli pliki są pod kontrolą wersji.

Jednak można to zrobić ręcznie.

Zacznij od utworzenia nowej, pożądanej struktury folderów - zignoruj ​​pliki .csproj i pliki rozwiązań na teraz, a także więcej plików .cs, które Cię interesują, do nowej struktury.

Teraz uruchom program Visual Studio i utwórz nowy, pusty projekt. Jeśli masz różne typy projektów, możesz utworzyć jeden nowy, pusty projekt dla każdego typu. Dzięki temu otrzymasz pusty plik .csproj oraz plik .sln z jednym projektem.

Skopiuj pusty plik projektu do miejsca, w którym jest on potrzebny, iw razie potrzeby zmień jego nazwę. Możesz je edytować i zmienić nazwę zespołu oraz domyślny obszar nazw, jeśli chcesz, lub zaczekaj, aż skończysz i zmień ustawienia za pomocą programu Visual Studio.

Na koniec edytuj plik .sln i usuń sekcję Projekt. Skopiuj pusty plik .sln tam, gdzie chcesz i otwórz go w Visual Studio. Teraz idź i dodaj każdy z istniejących projektów do nowego rozwiązania.

W ramach każdego projektu kliknij przycisk "Pokaż wszystko" i zacznij uwzględniać wszystkie pliki skopiowane do struktury projektu. Rozwiąż brakujące zależności, zmień przestrzenie nazw i nazwy zespołów dla projektu i upewnij się, że pliki kodu nie określają obszaru nazw, którego nie chcesz. Powtarzaj do końca.

Gdy otrzymasz nowe rozwiązanie do zbudowania, pomocne będzie otwarcie bibliotek DLL w Reflectorze, aby upewnić się, że nie pominąłeś żadnych deklaracji przestrzeni nazw w pliku kodu - jeśli próbujesz dostać się do punkt, w którym istnieje 1-1 relacja między DLL i przestrzenią nazw, a nawet zapewnienie, że żadne przestrzenie nazw nie są dzielone między bibliotekami DLL, Reflector jest twoim przyjacielem.

Powodzenia.