Określ plik projektu rozwiązania za pomocą msbuild


116

Chcę, aby wiersz poleceń do zbudowania konkretnego projektu rozwiązania za pomocą msbuild, tak jak robimy z devenv.com.W devenv.com możemy określić projekt rozwiązania za pomocą następującego wiersza poleceń

devenv.com /Build Release|x86 test.sln /project "testproject"

Korzystając z powyższego wiersza poleceń, mogę zbudować projekt testowy w pliku test.sln przy użyciu devenv.com. Jaka jest linia poleceń dla msbuild dla tego samego rozwiązania.

Dzięki


Czy jest jakiś powód, dla którego nie przekazujesz samego projektu testowego do msbuild?
Mark Smith

2
Ponieważ nie mogę już edytować mojego komentarza. Mam na myśli odniesienie do projektu bezpośrednio zamiast rozwiązania. „msbuild testproject / p: Configuration = Release / p: Platform = x86”
Mark Smith

inny czas muszę budować różne projekty. korzystając z devenv.com łatwo jest określić projekt tego rozwiązania
tjdoubts

Jeśli to jedyny problem, powinieneś być w stanie użyć msbuild do zbudowania potrzebnych projektów w odpowiednim czasie. Masz już różne polecenia, które wykonujesz w różnym czasie w rozwiązaniu, więc dlaczego nie odwoływać się do projektów w odpowiednim czasie za pomocą różnych poleceń msbuild? Jeśli twoje projekty są poprawnie skonfigurowane, powinny znaleźć wszystkie swoje odniesienia bez użycia pliku sln.
Mark Smith

Odpowiedzi:


202
msbuild test.sln /t:project /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false

Zwróć uwagę, że przypisano /tnazwę projektu w rozwiązaniu, która może różnić się od nazwy pliku projektu.

Ponadto, jak określono w jak: Tworzenie określonych celów w rozwiązaniach przy użyciu programu MSBuild.exe :

Jeśli nazwa projektu zawiera wszelkie znaki %, $, @, ;, ., (, ), lub 'wymienić je ze związkiem _w określonej nazwie docelowej.

Możesz także tworzyć wiele projektów jednocześnie:

msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false

Aby odbudować lub wyczyścić, zmień /t:projectna /t:project:cleanlub/t:project:rebuild


99
Jedna ważna uwaga: jeśli Twój projekt ma rozszerzenie „.” w nazwie, musisz zastąpić ją znakiem „_”, podając / t
Watusimoto

4
@easton W przypadku budowania wielu projektów składnia była taka, aby mój msbuild powtarzał /tparametr dla każdego projektu do zbudowania:msbuild test.sln /t:project /t:project2
Philippe

46
Ponadto, jeśli używasz folderu rozwiązania, musisz poprzedzić nazwę projektu nazwą folderu i ukośnikiem. Podobnie jak wspomniany powyżej @Watusimoto, jeśli w nazwie występują kropki (.), Należy je zastąpić podkreśleniami (_). Skończyło się coś takiego: /t:SlnFolder\My_Project_name.
Travis Parks

28
@TravisParks: Warto również wspomnieć, że „folder rozwiązania” nie odnosi się do folderu systemu plików, ale raczej do folderu w widoku eksploratora rozwiązań.
joshbodily

4
Musiałem także zamienić „(” i „)” na „_” w nazwie folderu (projekty wygenerowane przez GYP). Myślę, że wszystkie znaki specjalne są zastąpione podkreśleniem.
Maxime Viargues

15

Program MSBuild faktycznie działa przy użyciu projektów, a nie rozwiązania. Rozwiązanie jest używane tylko do analizowania go do tymczasowego pliku projektu w programie MSBuild wewnętrznie. Powinno być możliwe po prostu zbudowanie interesującego projektu bezpośrednio za pomocą programu MSBuild, wykonując następujące polecenie.

"msbuild testproject /p:Configuration=Release /p:Platform=x86"

Jest jeden poważny problem, o którym wiem, że możesz napotkać użycie projektu bezpośrednio zamiast rozwiązania: jeśli używasz rozwiązania do wyrażania zależności między projektami, zamiast dodawać odwołania do projektu i pozwolić systemowi kompilacji automatycznie opracować zależności .

Jeśli wymuszasz kolejność kompilacji za pomocą pliku sln, polecam pracę z tymi zależnościami bezpośrednio w plikach proj i usunięcie ich z sln. Umożliwi to bezpośrednie wywołanie dowolnego pliku proj z programu MSBuild, a wszystkie projekty będą kompilowane niezależnie bez dodatkowej pracy. Naprawdę powinieneś traktować plik sln jako grupę projektów, aby ułatwić pracę w programie Visual Studio, a nie jako dane wejściowe kompilacji.


4
Wskaż, w jaki sposób można wymusić kolejność kompilacji z plików proj. Dzięki.
ProgramCpp,

4
Oto kolejny problem z bezpośrednim użyciem nazwy projektu. Na przykład masz w swoim rozwiązaniu 5 projektów. Niektóre projekty mają konfigurację DebugPro, a inne nie. Jeśli tworzysz projekt z konfiguracją, w której wszystkie projekty mają wszystko, to plik, ale tylko plik rozwiązania wie, której konfiguracji projektu użyć dla każdego projektu, jeśli wybrano konfigurację rozwiązania DebugPro.
Alex

@ProgramCpp Kiedy dodajesz odwołania z jednego projektu do drugiego, automatycznie wykrywa, że ​​projekt, do którego się odwołujesz, musi najpierw zostać zbudowany.
jpaugh

Inną wadą tego podejścia jest to, że ścieżki względne w projekcie są rozwiązywane względem pliku rozwiązania. Po zbudowaniu projektu bezpośrednio względna ścieżka ulegnie zmianie. Dane wyjściowe mogą znajdować się w innym miejscu, a testy jednostkowe mogą wyszukiwać nieprawidłowe katalogi.
Tomas Kubes

Problemy mogą się również pojawić, jeśli używasz zmiennych rozwiązań w konfiguracji projektu, takich jak $ (SolutionDir)
Alex Che

8

Publikowanie jako informacja dla przyszłych poszukiwaczy

Dodaj poniższy kod do skryptu kompilacji i uruchom go raz. Spowoduje to wygenerowanie dokładnych celów i innych informacji, których będzie faktycznie używał msbuild.

Np .: jeśli masz .w nazwie projektu lub folderach, które msbuild będzie oczekiwał _zamiast ..

set MSBuildEmitSolution=1

Po uzyskaniu informacji zaktualizuj skrypt kompilacji o wymagane szczegóły.


6
`` Jeśli masz ''. w nazwie projektu lub w folderach msbuild będzie oczekiwał
znaku

2

Aby to zrobić, musisz wiedzieć, jaka jest nazwa docelowa projektu , niekoniecznie nazwa projektu.

Jednym ze sposobów, aby to sprawdzić, jest użycie programu MSBuild przeciwko SLN z zamierzonymi parametrami po ustawieniu specjalnej zmiennej środowiskowej wywoływanej MSBuildEmitSolutionna wartość 1.

set MSBuildEmitSolution=1
msbuild my_stuff.sln /t:rebuild /p:Configuration=Release /p:Platform=x64

Ostatnio musiałem to zrobić z powodu bardzo specyficznej nazwy celu w zagnieżdżonych katalogach. Więc z mojego wygenerowanego pliku my_stuff.sln.metaprojznalazłem tę linię:

<Target Name="Utils\Firewall\FirewallUtils:Rebuild">

Oznacza to, że wiersz poleceń kończy się na

msbuild my_stuff.sln /t:Utils\Firewall\FirewallUtils:Rebuild /p:Configuration=Release /p:Platform=x64

2
To było to, czego potrzebowałem. Wskazówka, jeśli nie chcesz tego uruchamiać: celem jest struktura folderów od bieżącej ścieżki do pliku projektu, bez rozszerzenia pliku projektu ( .csprojw moim przypadku). I <3 SO!
Brak zwrotów Brak zwrotów

1

Aby dodać dodatkowe informacje, wykonanie msbuild w folderze projektu domyślnie skompiluje plik projektu, ponieważ jest to jedyny tam.

>msbuild

Istnieje wiele odmian korzystania z msbuild w ten sposób. Możesz określić plik proj bezpośrednio.

>msbuild helloworld.csproj -t:Build.

Przejrzyj dokumentację msbuild pod kątem użycia, wymagań dotyczących plików proj, a także korzyści z kompilowania projektu zamiast rozwiązania.

Dokumentacja MSBuild

Takie budowanie ma zalety, o czym wspomniał wyżej mark-smith.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.