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

— tjdoubts
źródło

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

2

Możliwy duplikat Zbuduj tylko jeden projekt w rozwiązaniu z wiersza poleceń

— UuDdLrLrSs

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

— Easton L.
źródło

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.

— Mark Smith
źródło

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.

— freshprinze
źródło

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

— kayleeFrye_onDeck
źródło

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.

— CJ
źródło