2009-05-29 10 views

Odpowiedz

8

Oto rzeczywisty przykład, że ułożyła, że ​​pokazuje to, czego szukali:

<?xml version="1.0" encoding="utf-8"?> 
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Test" ToolsVersion="3.5"> 

    <!--Declare an ItemGroup that points to your file you want to copy.--> 
    <ItemGroup> 
    <ItemToCopy Include=".\Home.aspx" /> 
    </ItemGroup> 

    <!--Declare an ItemGroup that points to your destination Locations--> 
    <ItemGroup> 
    <DestLocations Include=".\abc\home.aspx" /> 
    <DestLocations Include=".\def\home.aspx" /> 
    <DestLocations Include=".\ghi\home.aspx" /> 
    </ItemGroup> 

    <Target Name="CopyFiles"> 
    <!--Run the copy command to copy the item to your dest locations--> 
    <!--This is where the magic happens. The % sign before the DestLocations reference says to use 
    Batching. So Copy will be run for each unique FullPath MetaData in the DestLocations ItemGroup.--> 
    <Copy SourceFiles="@(ItemToCopy)" DestinationFolder="%(DestLocations.FullPath)" /> 
    </Target> 
</Project> 
+0

Świetnie. Dzięki, komentarze sprawiają, że jest to bardzo jasne. Wiem, że mogę zabrzmieć trochę płytko, jeśli mówię, że nie chcę zostać guru MSBuild, raczej tylko rozwiązam mój problem tutaj. Zauważyłem, że dzięki zastosowaniu przypadku technologii przez przypadek jest to punkt w krzywej uczenia się, gdzie masz dość rozproszonej wiedzy, że całonocne badanie od zera jest znacznie łatwiejsze i umieszcza wszystko na swoim miejscu. Uważam, że często jest to lepszy sposób na naukę. –

+1

Jeśli nie musisz znać tego wszystkiego teraz, to działa dobrze. Naprawiłem błąd w przykładzie (przepraszam za to). Musisz wywołać dowolne zadania (np. Kopię) w celu. Wrzuciłem go do celu. Wywołujesz wywołanie MSBuild z tą nazwą docelową (CopyFiles), a on uruchomi cel. – Vaccano

0

Naprawdę najlepiej sobie z tym radzisz jako ćwiczeniem edukacyjnym, zamiast traktować MSBUILD jako magiczne pudełko. This article from Patrick Smacchia podaje większość stosowanych technik.

+0

Jestem rzeczywiście próbuje do zapoznania się z MSBuild próbując zautomatyzować wiele zadań robiłem ręcznie aż dzisiaj. Czytałem kilka samouczków podobnych do tego, do którego się odwołujesz (wydaje się, że jest to mnóstwo kopii). Czyniąc to, staram się zapoznać ze składnią i wbudowanymi możliwościami. Czy mógłbyś wyjaśnić, jak traktuję to jak magiczne pudełko i jak Twój artykuł może mnie oświecić? –

+0

Hej, Boris, nie myślałem, że "traktujesz to jak czarną skrzynkę", kiedy jesteś leniwy. Głównie myślałem o moim czasie nauki msbuild - próbowałem zrozumieć zadanie na raz, ale nie ogólny obraz. Naprawdę znalazłem artykuł Smacchia, który był czymś, co chciałem mieć tydzień przed tym, jak go otrzymałem. Jako autor NDepend, nie jest on przecinanym kupcem. Jeśli chodzi o definiowanie listy, wyobrażam sobie, że dla listy działałaby właściwość [xml list], a następnie skorzystasz z zadania Kopiuj z listą obiektów do zapętlenia/symboli wieloznacznych, aby przejść tę listę. Nie zrobiłem tego sam - w przeciwnym wypadku wkleiłbym próbkę. –

+0

Dziękuję za odpowiedź. Będę miał dogłębne spojrzenie na artykuł. –

2

koncepcji, że powinieneś być zainteresowany jest znany jako Batching.

ja omówiliśmy dokładnie ten scenariusz na moim blogu na http://www.sedodream.com/PermaLink,guid,5f1e0445-ce3d-4052-ba80-42fd19512d42.aspx

Oto tekst tego wpisu na blogu, możesz pobrać wymienione pliki pod powyższym linkiem.


Dzisiaj ktoś opowiadał mi o współpracowniku, który miał problemy z MSBuild. Powiedział mi, że próbował skopiować zestaw plików do zestawu różnych serwerów. Problem polegał jednak na tym, że nie wiedział, jak to osiągnąć, bez wykonywania wielu wywołań zadania Kopiuj. Powiedziałem mu, że może to osiągnąć za pomocą MSBuild Batching. Partie to proces wykonywania zadania (lub celu) na zestawie elementów (partii) na raz. Partia może również zawierać pojedynczy element. Tak więc w tym scenariuszu musimy wykonać kopię raz dla każdego serwera, który chciał wdrożyć. Stworzyłem prosty plik msbuild, który demonstruje to na dwa różne sposoby. Pierwszy sposób wykorzystuje grupowanie zadań, które można zobaczyć w celu testowym. Drugi używa partii docelowej, którą można zobaczyć w celu DoItCore. Stworzyłem także czysty cel, który nie ma nic wspólnego z dozowaniem.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Test"> 

     <ItemGroup> 
      <SourceFiles Include="*.txt"/> 
      <Dest Include="One;Two;Three;Four;Five"/> 
     </ItemGroup> 

     <Target Name="Test"> 
      <Copy SourceFiles ="@(SourceFiles)" DestinationFolder="%(Dest.FullPath)"/> 
      <Message Text="Fullpath: %(Dest.FullPath)"/> 
     </Target> 


     <!-- These targets demonstrate target batching --> 
     <Target Name="DoIt" DependsOnTargets="DoItCore"/> 
     <Target Name="DoItCore" Inputs="@(SourceFiles)" Outputs="%(Dest.FullPath)"> 
      <Copy SourceFiles="@(SourceFiles)" DestinationFolder="%(Dest.FullPath)"/> 
     </Target> 


     <!-- This will clean up the files --> 
     <Target Name="Clean"> 
      <CreateItem Include="%(Dest.FullPath)\**\*"> 
        <Output ItemName="FilesToDelete" TaskParameter="Include"/> 
      </CreateItem> 
      <Delete Files="@(FilesToDelete)"/> 
     </Target> 
</Project> 

Wiązanie jest zaawansowanym tematem MSBuild i jest zdecydowanie zaniedbane. Muszę przyznać, że jestem winny, że nie piszę o tym wystarczająco. Istnieje kilka dobrych zasobów porcjowania, są one wymienione poniżej.


Oto kilka innych blogów, które zamieściłem.

Dzięki, Sayed Ibrahim Hashimi

My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

+0

Jeśli rozumiem konwencję, aby je rozdzielić za pomocą ";" sprawia, że ​​parametr jest listą, a nie pojedynczym elementem. Sprawdzę to po godzinach pracy. Dzięki –

Powiązane problemy