2011-10-04 9 views
10

Wykonuję MSBuild z pliku wsadowego. Skrypt MSBuild znajduje się w innym katalogu niż katalog, który chcę, aby MSBuild rozważał katalog roboczy podczas uruchamiania skryptu. Podczas wywoływania programu MSBuild.exe, w jaki sposób mogę zmienić jego katalog roboczy?Zmiana katalogu roboczego msbuild.exe

Edit: Więcej szczegółów
powiedzmy Mam skrypt MSBuild znajdujący się na innym serwerze. Chcę uruchomić polecenie w następujący sposób:

msbuild.exe \\my_server\c$\My\Path\To\Scripts\TestScript.msbuild 

Uruchomię to polecenie z wiersza polecenia na c: \ temp. Załóżmy, że mój TestScript.msbuild ma zadanie utworzenia pliku. Plik nie ma ścieżki tylko nazwa pliku. Spodziewam się, że plik zostanie utworzony wewnątrz c: \ temp. Ale nie tworzy się obok pliku msbuild, który znajduje się na serwerze. To jest zachowanie, które chcę zmienić.

Edit # 2
Oto skrypt używam w moim teście:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <ItemGroup> 
     <Files Include="HelloWorld.txt" /> 
    </ItemGroup> 

    <Target Name="TouchFiles"> 
     <Touch Files="@(Files)" AlwaysCreate="True" /> 
    </Target> 
</Project> 

jadę do poleceń powłoki CDing do c: \ temp, a następnie wykonanie skryptu. Z lub bez przełącznika/p: OutDir, o którym wspomina @Nick Nieslanik, plik HelloWorld.txt pojawia się w folderze, w którym znajduje się plik * .msbuild, a nie c: \ temp.

+0

Nie jestem pewien, czy rozumiem twoje pytanie. Jeśli mam plik cmd w katalogu A i wywołuję go z katalogu B, to echo% cd% spowoduje wyświetlenie katalogu B jako bieżącego katalogu. Więc jeśli nie zmienisz katalogu w skrypcie, powinien on już uważać aktualny katalog jako katalog roboczy. Możesz wyjaśnić? –

+0

Zgadzam się z zachowaniem, które opisujesz. Jednak MSBuild nie wydaje się tego robić. Wydaje się, że lokalizacja pliku * .build jest katalogiem roboczym. Zmienię moje pytanie, aby opisać więcej szczegółów w mojej konfiguracji. – RationalGeek

Odpowiedz

3

@jkohlhepp - Teraz widzę. W pewnym stopniu robisz coś przeciwnego do tego, co opisałem w swoim komentarzu.
Wspólne cele MSBuild używają MSBuildProjectDirectory do określenia folderu wyjściowego, chyba że go przesłonisz. Więc w twoim przypadku można uruchomić

msbuild.exe \\my_server\c$\My\Pat\To\Scripts\TestScript.msbuild /p:OutDir=c:\temp 

wymusić wyjście, aby zostać pominięte w tym miejscu.

EDIT:
Biorąc pod uwagę powyższy plik projektu, trzeba by go zmienić, by zrobić coś jak następuje to zadziałało:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup> 
    <OutDir Condition=" '$(OutDir)' == '' ">bin\debug\</OutDir> 
    </PropertyGroup> 
    <ItemGroup> 
    <!-- Without prefacing files with paths, they ar assumed relative to the proj file --> 
    <FilesToCreate Include="$(OutDir)HelloWorld.txt" /> 
    </ItemGroup> 
    <Target Name="TouchFiles"> 
    <Touch Files="@(FilesToCreate)" AlwaysCreate="True" /> 
    </Target> 
</Project> 
+0

Hmmmmm .... to nie działa dla mnie. W moim przykładowym skrypcie, który zbudowałem dla tego pytania, mam zadanie , które określa tylko nazwę pliku, bez katalogu. Nawet jeśli podam opcję/p: Outdir = c: \ temp, dotknięty plik nadal kończy się obok pliku skryptu msbuild. – RationalGeek

+0

Czy możesz pokazać trochę tego pliku msbuild w pytaniu? –

+0

Tak, mogę. Dodano pełny skrypt do pytania. – RationalGeek

16

natknąłem tej chwili szuka rozwiązania do mojego problem. Oto moje rozwiązanie (skrypt budujący):

<?xml version="1.0" encoding="utf-8"?> 
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <Target Name="Default"> 
    <Exec Command="build.bat" WorkingDirectory="..\[your dir]\" /> 
    </Target> 
</Project> 

Uważam, że jest to coś więcej, czego początkowo szukasz?

Mój problem polegał na tym, że mój plik wsadowy o nazwie inny, który powinien znajdować się w tym samym katalogu, ale ponieważ mój skrypt budujący ms był uruchamiany gdzie indziej, plik wsadowy nie znalazł drugiego pliku wsadowego.

+0

Uratowałeś mi życie. Kod wyjścia 99, begone. – mmmeff

+0

Atrybut 'WorkingDirectory' był tym, czego szukałem. Stukrotne dzięki! –

Powiązane problemy