Jak korzystać z dirs.proj?

Question

Obawiam się, że mogę zadawać naprawdę głupie pytanie, ale nie mogę znaleźć niczego, co by to wyjaśniało. Zwykle pracuję na mniejszych aplikacjach, ale pracuję teraz nad większym zestawem kilku zestawów w podstawowej strukturze i kilkoma złożeniami dla domeny linii produktów (z bardziej przyszłymi). Chciałbym zarządzać kompilacją, konfigurując MSBuild. Zrobiłem wiele badań online (w szczególności z kilkoma artykułami MSDN, które znalazłem) i teraz czuję się wystarczająco dobrze, aby być niebezpiecznym.

Rozumiem, że w programie csharp plik * .csproj może zostać rozładowany i zmodyfikowany za pomocą właściwości, elementów i obiektów docelowych w celu kontrolowania procesu budowania. Rozumiem również, że mogę zaimportować plik własnych celów, aby pomóc w oddzieleniu i uporządkowaniu. W tym jednak łączu (https://msdn.microsoft.com/en-us/magazine/dd483291.aspx) wielopoziomowa kompilacja projektu jest zorganizowana z plikami dirs.proj na poziomie węzłów. Jest to mylące i postawiłem kilka pytań, na które nie mogę znaleźć odpowiedzi:

1. Jaka jest różnica w pliku * .proj i * .csproj?
2. Czy * .proj można skonfigurować w VS, aby załadować na Build za pomocą F6 lub czy wymaga tego użycie tylko wiersza poleceń? ("msbuild dirs.proj/t: Build").
3. Czy dirs.proj ładuje się automatycznie? Jeśli tak, moje badanie nie działa poprawnie, ale robi to z wiersza polecenia.
4. Czy mogę przeoczyć coś z dookoła za pomocą "dirs.proj" Może to po prostu nazwa substytutu jednego z plików projektu * .csproj? Gdyby tak było, nie byłoby potrzeby, aby dirs.proj węzła głównego, z tego, co wiem, nie wiąże się z faktycznym projektem.

Anyways, widziałem dirs.proj wspomniano w kilku forach dotyczących kwestii, ale nie ma gdzie mogę znaleźć jak to jest załadowany lub wykorzystywane w VS (poza poleceń obsługi szybkiej budynku, który wydaje się nieuzasadnione, jeśli to służy do zorganizuj budowę, ale budowa nie zajmie dużo czasu). Mam nadzieję, że ktoś może mi w tym pomóc.

Z góry dziękuję.

Answer 1

Dirs.proj to konwencja MSBuild zazwyczaj używana w przypadku bardzo dużych drzew źródłowych (> 20 projektów). Pracowałem z inżynierami Microsoftu w poprzedniej firmie i konwencja dirs.proj wydaje się być tą, którą Microsoft opracował i wykorzystuje wewnętrznie do zarządzania bardzo dużymi drzewami źródłowymi.

Bardzo dobrym referencją do realizacji tego jest projekt Python Tools for Visual Studio na CodePlex.

The link you shared by Sayed Ibrahim Sashimi jest bardzo dobrym wyjaśnieniem argumentów za paradygmatem msbuild, ale nie robi to zbyt dobrze pokazując praktyczny przykład jak to działa. Projekt Python Tools jest doskonałym referencją dla tego.

Pomysł użycia tego paradygmatu jest prosty. Założę się, że większość programistów oprogramowania .NET pracuje na nieco ograniczonych projektach, które nie zajmują się więcej niż 5-10 projektami na raz, i zarządzają tymi projektami w Visual Studio poprzez rozwiązania (.sln) . Mogą nawet poinstruować ich system kompilacji, aby uruchamiał kompilacje na .sln. Działa to dobrze, dopóki nie zaczniesz myśleć o skalowaniu produktu lub łączeniu go z czymś większym, takim jak platforma z wieloma, wieloma projektami. Pliki rozwiązania nie są plikami MSBuild i jako takie nie są rozszerzalne, podobnie jak MSBuild i ponoszą ogromne kary za wydajność w przypadku dużej liczby projektów.

Z perspektywy MSBuild dirs.proj oznacza pliki Visual Studio .sln. Różnica polega jednak na tym, że dirs.proj nie obejmują.csproj (i tym podobne) jako .sln, raczej mogą zawierać poddrzewo źródłowe (np. inne zagnieżdżone dirs.proj). Tak więc budowanie katalogu głównego dirs.proj może spowodować zbudowanie całego drzewa źródłowego lub zbudowanie zagnieżdżonego dirs.proj spowoduje zbudowanie tego poddrzewa.

Dlatego paradygmat zachęca do spojrzenia na swoje źródło jako serię współzależnych węzłów zorganizowanych w funkcje lub obszary produktów. W ten sposób inżynierowie mogą pracować na różnych źródłowych poddrzewach w bardzo dużych projektach bez konieczności zajmowania się całym drzewem źródłowym, tak jak w przypadku rozwiązania VS.

Korzystanie z tego paradygmatu wiąże się również z pewnymi korzyściami, które nie są dostarczane z plikami .sln. Na przykład, jeśli jeden projekt odwołuje się do projektu z innego, osobnego poddrzewa, to MSbuild automatycznie zbuduje to odwołanie. Ponadto węzły źródłowe mogą mieć własne ustawienia kompilacji, co pozwala na dynamiczne budowanie przy użyciu różnych ustawień kompilacji w oparciu o scenariusz kompilacji. Na przykład w jednym scenariuszu poddrzewa źródłowego SharePoint potrzebuje pakietu WSP, podtrener C# musi być zbudowany bez .pdb, subtree DB musi generować dacpaki, a całe drzewo źródłowe musi podpisywać swoje złożenia za pomocą myCorp.snk i ustawić kompilację wyjście do katalogu $ (buildRoot) \ Output.

dirs.proj nie są otwierane przez studio graficzne - są budowane z wiersza poleceń za pomocą msbuild. Jedynym problemem jest to, że pliki muszą być ręcznie obsługiwane.

Krótko mówiąc, spójrz na projekt Python Tools i zobacz, jak używają dirs.proj. Zwróć uwagę, jak całe drzewo źródłowe ma wspólne ustawienia zarządzane przez Common.Build.settings i jak właściwości msbuild w tym pliku .settings są używane w różnych plikach .csproj.