Objaśnienie procesu kompilacji

Autor Jason Lewandowski

Pobierz plik PDF

Ten temat zawiera Przewodnik po procesie kompilowania i wdrażania w skali przedsiębiorstwa. Metoda opisana w tym temacie używa niestandardowych plików projektu Microsoft Build Engine (MSBuild) w celu zapewnienia precyzyjnej kontroli nad każdym aspektem procesu. W ramach plików projektu niestandardowe cele programu MSBuild są używane do uruchamiania narzędzi do wdrażania, takich jak narzędzie Web Deployment Internet Information Services (IIS), a narzędzie do wdrażania bazy danych VSDBCMD. exe.

Note

W poprzednim temacie opisano plik projektu, opisnajważniejszych składników pliku projektu programu MSBuild i wprowadzono koncepcję podziału plików projektu w celu obsługi wdrożenia w wielu środowiskach docelowych. Jeśli nie znasz już tych koncepcji, przed rozpoczęciem pracy z tym tematem należy zapoznać się z tematem plik projektu .

Ten temat stanowi część szeregu samouczków opartych na wymaganiach dotyczących wdrażania w przedsiębiorstwie fikcyjnej firmy o nazwie Fabrikam, Inc. W tej serii samouczków jest stosowane—przykładowe rozwiązanie—do reprezentowania aplikacji sieci Web, które marealistyczny poziom złożoności, w tym aplikacji ASP.NET MVC 3, usługi Windows Communication Foundation (WCF) i projektu bazy danych.

Metoda wdrażania w tym samouczku jest oparta na rozłożeniu pliku projektu dzielonego opisanym w artykule Omówienie pliku projektu, w którym proces kompilacji jest kontrolowany przez dwa pliki—projektu, zawierający instrukcje kompilacji, które mają zastosowanie do każdego środowiska docelowego, oraz jeden zawierający ustawienia kompilacji i wdrożenia specyficznego dla środowiska. W czasie kompilacji plik projektu specyficzny dla środowiska jest scalany z plikiem projektu Environment-niezależny od w celu utworzenia kompletnego zestawu instrukcji kompilacji.

Przegląd Kompilowanie i wdrażanie

W rozwiązaniu Contact Managertrzy pliki kontrolują proces kompilowania i wdrażania:

  • Plik uniwersalnego projektu (Publish. proj). Zawiera instrukcje kompilacji i wdrażania, które nie zmieniają się między środowiskami docelowymi.
  • Plik projektu specyficzny dla środowiska (ENV-dev. proj). Zawiera ustawienia kompilacji i wdrożenia, które są specyficzne dla określonego środowiska docelowego. Na przykład można użyć pliku ENV. proj , aby podać ustawienia dla środowiska deweloperskiego lub testowego i utworzyć alternatywny plik o nazwie ENV-Stage. proj , aby podać ustawienia środowiska przejściowego.
  • Plik polecenia (Publish-dev. cmd). Zawiera polecenie MSBuild. exe, które określa pliki projektu, które chcesz wykonać. Można utworzyć plik poleceń dla każdego środowiska docelowego, gdzie każdy plik zawiera polecenie MSBuild. exe, które określa inny plik projektu specyficzny dla środowiska. Dzięki temu deweloper może wdrożyć się w różnych środowiskach, uruchamiając odpowiedni plik polecenia.

W przykładowym rozwiązaniu można znaleźć te trzy pliki w folderze publikowanie rozwiązania.

Zanim zaczniesz bardziej szczegółowo oglądać te pliki, przyjrzyjmy się, jak cały proces kompilacji działa podczas korzystania z tego podejścia. Na wysokim poziomie proces kompilowania i wdrażania wygląda następująco:

W pierwszej kolejności następuje, że dwa pliki—projektu, które zawierają instrukcje dotyczące kompilowania i wdrażania, a jedna z nich zawiera ustawienia—specyficzne dla środowiska, są scalane w jeden plik projektu. Następnie program MSBuild działa przez instrukcje w pliku projektu. Kompiluje wszystkie projekty w rozwiązaniu przy użyciu pliku projektu dla każdego projektu. Następnie wywołuje on inne narzędzia, takie jak Web Deploy (MSDeploy. exe) i narzędzie VSDBCMD do wdrażania zawartości sieci Web i baz danych w środowisku docelowym.

Od początku do końca proces kompilowania i wdrażania wykonuje następujące zadania:

  1. Usuwa zawartość katalogu wyjściowego w przygotowaniu dla nowej kompilacji.

  2. Kompiluje każdy projekt w rozwiązaniu:

    1. W przypadku projektów—sieci Web w tym przypadku aplikacja sieci Web ASP.NET MVC i usługa—sieci Web programu WCF proces kompilacji tworzy pakiet wdrożeniowy sieci Web dla każdego projektu.
    2. W przypadku projektów bazy danych proces kompilacji tworzy manifest wdrożenia (plik. deploymanifest) dla każdego projektu.
  3. Używa narzędzia VSDBCMD. exe do wdrożenia każdego projektu bazy danych w rozwiązaniu przy użyciu różnych właściwości z plików—projektu, docelowego ciągu połączenia i nazwy—bazy danych wraz z plikiem. deploymanifest.

  4. Używa narzędzia MSDeploy. exe do wdrożenia każdego projektu sieci Web w rozwiązaniu przy użyciu różnych właściwości z plików projektu w celu sterowania procesem wdrażania.

Możesz użyć przykładowego rozwiązania do śledzenia tego procesu bardziej szczegółowo.

Note

Aby uzyskać wskazówki dotyczące dostosowywania plików projektu specyficznych dla środowiska dla własnych środowisk serwera, zobacz Konfigurowanie właściwości wdrożenia dla środowiska docelowego.

Wywoływanie procesu Kompilowanie i wdrażanie

Aby wdrożyć rozwiązanie Contact Manager w środowisku testowym dewelopera, programista uruchamia plik poleceń Publish-dev. cmd . Powoduje to wywołanie programu MSBuild. exe, określającego plik Publish. proj jako pliku projektu do wykonania i ENV-dev. proj jako wartości parametru.

msbuild.exe Publish.proj /fl /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj

Note

Przełącznik /FL (Short for /FileLogger) rejestruje dane wyjściowe kompilacji do pliku o nazwie MSBuild. log w bieżącym katalogu. Aby uzyskać więcej informacji, zobacz informacje dotyczące wiersza polecenia programu MSBuild.

W tym momencie program MSBuild zacznie działać, ładuje plik Publish. proj i zacznie przetwarzać zawarte w nim instrukcje. Pierwsza instrukcja instruuje program MSBuild, aby zaimportował plik projektu, który określa parametr TargetEnvPropsFile .

<Import Project="$(TargetEnvPropsFile)" />

Parametr TargetEnvPropsFile określa plik ENV. proj , dlatego program MSBuild Scala zawartość pliku ENV-dev. proj z plikiem Publish. proj .

Kolejne elementy, które program MSBuild napotka w scalonym pliku projektu, są grupami właściwości. Właściwości są przetwarzane w kolejności, w jakiej występują w pliku. Program MSBuild tworzy parę klucz-wartość dla każdej właściwości, co zapewnia spełnienie wszelkich określonych warunków. Właściwości zdefiniowane w dalszej części pliku zastąpią wszystkie właściwości o tej samej nazwie zdefiniowanej wcześniej w pliku. Rozważmy na przykład właściwości OutputRoot .

<OutputRoot Condition=" '$(OutputRoot)'=='' ">..\Publish\Out\</OutputRoot>
<OutputRoot Condition=" '$(BuildingInTeamBuild)'=='true' ">$(OutDir)</OutputRoot>

Gdy MSBuild przetwarza pierwszy element OutputRoot , dostarczenie parametru o podobnej nazwie nie zostało dostarczone, ustawia wartość właściwości OutputRoot na . \Publish\Out. Gdy napotka drugi element OutputRoot , jeśli wynikiem warunku jest true, nadpisze wartość właściwości OutputRoot wartością parametru OutDir .

Następny element, którego wystąpienie MSBuild występuje, jest grupą pojedynczego elementu zawierającego element o nazwie ProjectsToBuild.

<ItemGroup>
   <ProjectsToBuild Include="$(SourceRoot)ContactManager-WCF.sln"/>
</ItemGroup>

Program MSBuild przetwarza tę instrukcję, tworząc listę elementów o nazwie ProjectsToBuild. W takim przypadku lista elementów zawiera jedną wartość—ścieżka i nazwa pliku rozwiązania.

W tym momencie pozostałe elementy są obiektami docelowymi. Elementy docelowe są przetwarzane inaczej od właściwości i—elementów, dlatego elementy docelowe nie są przetwarzane, chyba że zostały jawnie określone przez użytkownika lub wywołane przez inną konstrukcję w pliku projektu. Odwołaj, że tag otwierającego projektu zawiera atrybut DefaultTargets — .

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

Powoduje to, że program MSBuild wywoła element docelowy FullPublish , jeśli nie określono elementów docelowych podczas wywoływania programu MSBuild. exe. Element docelowy FullPublish nie zawiera żadnych zadań. Zamiast tego określa listę zależności.

<PropertyGroup>   
  <FullPublishDependsOn>
     Clean;
     BuildProjects;      
     GatherPackagesForPublishing;
     PublishDbPackages;
     PublishWebPackages;
  </FullPublishDependsOn>
</PropertyGroup>
<Target Name="FullPublish" DependsOnTargets="$(FullPublishDependsOn)" />

Ta zależność informuje program MSBuild, że w celu wykonania elementu docelowego FullPublish musi wywołać tę listę elementów docelowych w podanej kolejności:

  1. Musi wywołać czysty element docelowy.
  2. Musi wywołać element docelowy BuildProjects .
  3. Musi wywołać element docelowy GatherPackagesForPublishing .
  4. Musi wywołać element docelowy PublishDbPackages .
  5. Musi wywołać element docelowy PublishWebPackages .

Czysty element docelowy

Czysty obiekt docelowy zasadniczo usuwa katalog wyjściowy i całą jego zawartość jako przygotowanie do nowej kompilacji.

<Target Name="Clean" Condition=" '$(BuildingInTeamBuild)'!='true' ">
  <Message Text="Cleaning up the output directory [$(OutputRoot)]"/>
  <ItemGroup>
     <_FilesToDelete Include="$(OutputRoot)**\*"/>
  </ItemGroup>
  <Delete Files="@(_FilesToDelete)"/>
  <RemoveDir Directories="$(OutputRoot)"/>
</Target>

Zwróć uwagę, że element docelowy zawiera element Item . Podczas definiowania właściwości lub elementów w elemencie docelowym są tworzone dynamiczne właściwości i elementy. Innymi słowy, właściwości lub elementy nie są przetwarzane do momentu wykonania obiektu docelowego. Katalog wyjściowy może nie istnieć lub zawierać pliki do momentu rozpoczęcia procesu kompilacji, więc nie można utworzyć listy _FilesToDelete jako elementu statycznego; musisz poczekać do momentu wykonania operacji. W związku z tym można skompilować listę jako element dynamiczny w miejscu docelowym.

Note

W tym przypadku, ponieważ czysty element docelowy jest pierwszy do wykonania, nie ma rzeczywistej potrzeby używania dynamicznej grupy elementów. Jednak dobrym sposobem jest użycie właściwości dynamicznych i elementów w tym typie scenariusza, ponieważ może być konieczne wykonanie obiektów docelowych w innej kolejności w pewnym momencie.
Należy również zadbać o uniknięcie deklarowania elementów, które nigdy nie będą używane. Jeśli masz elementy, które będą używane tylko przez określony obiekt docelowy, Rozważ umieszczenie ich wewnątrz elementu docelowego, aby usunąć wszelkie niepotrzebne obciążenia w procesie kompilacji.

Elementy dynamiczne poza tym czysty element docelowy jest dość prosty i korzysta z wbudowanego komunikatu, usuwaniai RemoveDir — zadań do:

  1. Wyślij wiadomość do rejestratora.
  2. Utwórz listę plików do usunięcia.
  3. Usuń pliki.
  4. Usuń katalog wyjściowy.

Element docelowy BuildProjects

Obiekt docelowy BuildProjects zasadniczo kompiluje wszystkie projekty w przykładowym rozwiązaniu.

<Target Name="BuildProjects" Condition=" '$(BuildingInTeamBuild)'!='true' ">
   <MSBuild Projects="@(ProjectsToBuild)"
            Properties="OutDir=$(OutputRoot);
                        Configuration=$(Configuration);
                        DeployOnBuild=true;
                        DeployTarget=Package"
            Targets="Build" />
  </Target>

Ten element docelowy został opisany szczegółowo w poprzednim temacie, opisując plik projektu, aby zilustrować, w jaki sposób zadania i elementy docelowe odwołują się do właściwości i elementów. W tym momencie jesteś głównie zainteresowani zadaniami programu MSBuild . To zadanie służy do kompilowania wielu projektów. Zadanie nie tworzy nowego wystąpienia programu MSBuild. exe; używa bieżącego uruchomionego wystąpienia do kompilowania każdego projektu. Kluczowe znaczenie w tym przykładzie są właściwościami wdrożenia:

  • Właściwość DeployOnBuild instruuje program MSBuild, aby uruchomił wszystkie instrukcje wdrożenia w ustawieniach projektu, gdy kompilacja każdego projektu została ukończona.
  • Właściwość DeployTarget identyfikuje obiekt docelowy, który ma zostać wywołany po skompilowaniu projektu. W takim przypadku obiekt docelowy pakietu kompiluje dane wyjściowe projektu do wdrożonego pakietu sieci Web.

Note

Obiekt docelowy pakietu wywołuje potok publikowania w sieci Web (WPP), który zapewnia integrację między programem MSBuild i Web Deploy. Jeśli chcesz zapoznać się z wbudowanymi obiektami docelowymi, które zapewnia WPP, przejrzyj plik Microsoft. Web. Publishing. targets w folderze% ProgramFiles (x86)% \ MSBuild\Microsoft\VisualStudio\v10.0\Web.

Element docelowy GatherPackagesForPublishing

Jeśli analizujesz element docelowy GatherPackagesForPublishing , zauważysz, że nie zawiera on żadnych zadań. Zamiast tego zawiera jedną grupę elementów, która definiuje trzy elementy dynamiczne.

<Target Name="GatherPackagesForPublishing">
   <ItemGroup>
      <PublishPackages 
         Include="$(_ContactManagerDest)ContactManager.Mvc.deploy.cmd">
         <WebPackage>true</WebPackage>
         <!-- More item metadata -->  
      </PublishPackages>
      <PublishPackages 
         Include="$(_ContactManagerSvcDest)ContactManager.Service.deploy.cmd">
         <WebPackage>true</WebPackage>
         <!-- More item metadata -->
      </PublishPackages>
      <DbPublishPackages Include="$(_DbDeployManifestPath)">
         <DbPackage>true</DbPackage>
         <!-- More item metadata -->
      </DbPublishPackages>
   </ItemGroup>
</Target>

Te elementy odnoszą się do pakietów wdrożeniowych, które zostały utworzone podczas wykonywania elementu docelowego BuildProjects . Nie można zdefiniować tych elementów statycznie w pliku projektu, ponieważ pliki, do których odwołują się elementy, nie istnieją do momentu wykonania elementu docelowego BuildProjects . Zamiast tego elementy muszą być zdefiniowane dynamicznie w obiekcie docelowym, który nie jest wywoływany do momentu wykonania BuildProjects elementu docelowego.

Elementy nie są używane w tym elemencie docelowym—po prostu kompilują elementy i metadane skojarzone z każdą wartością elementu. Po przetworzeniu tych elementów element PublishPackages będzie zawierał dwie wartości, ścieżkę do pliku ContactManager. MVC. deploy. cmd i ścieżkę do pliku ContactManager. Service. deploy. cmd . Web Deploy tworzy te pliki jako część pakietu sieci Web dla każdego projektu i są to pliki, które należy wywołać na serwerze docelowym w celu wdrożenia pakietów. Jeśli otworzysz jeden z tych plików, zobaczysz polecenie MSDeploy. exe z różnymi wartościami parametrów specyficznych dla kompilacji.

Element DbPublishPackages będzie zawierać pojedynczą wartość, ścieżkę do pliku ContactManager. Database. deploymanifest .

Note

Podczas kompilowania projektu bazy danych jest generowany plik. deploymanifest, który używa tego samego schematu co plik projektu MSBuild. Zawiera wszystkie informacje wymagane do wdrożenia bazy danych, w tym lokalizację schematu bazy danych (DbSchema) i szczegółowe informacje o wszystkich skryptach przed wdrożeniem i po wdrożeniu. Aby uzyskać więcej informacji, zobacz omówienie Kompilowanie i wdrażanie bazy danych.

Dowiesz się więcej na temat tworzenia i używania pakietów wdrożeniowych oraz manifestów wdrażania bazy danych, a następnie tworzenia i pakowania projektów aplikacji sieci Web oraz wdrażania projektów bazy danych.

Element docelowy PublishDbPackages

Krótko mówiąc, obiekt docelowy PublishDbPackages wywołuje narzędzie VSDBCMD, aby wdrożyć bazę danych ContactManager w środowisku docelowym. Konfigurowanie wdrażania bazy danych obejmuje wiele decyzji i wszystkie szczegóły. dowiesz się więcej na ten temat w temacie wdrażanie projektów bazy danych i Dostosowywanie wdrożeń baz danych w wielu środowiskach. W tym temacie omówiono sposób działania tego elementu docelowego w rzeczywistości.

Najpierw należy zauważyć, że tag otwierający zawiera atrybut Output .

<Target Name="PublishDbPackages" Outputs="%(DbPublishPackages.Identity)">

Jest to przykład tworzenia wsadowych elementów docelowych. W plikach projektów programu MSBuild przetwarzanie wsadowe jest techniką do iteracji nad kolekcjami. Wartość atrybutu Outputs "% (DbPublishPackages. Identity)" odwołuje się do właściwości Metadata Identity listy elementów DbPublishPackages . Ten zapis, * Output =% * * * (ITEMLIST. ItemMetaDataName) , jest tłumaczony jako:

  • Podziel elementy w DbPublishPackages na partie elementów, które zawierają tę samą wartość metadanych tożsamości .
  • Wykonaj element docelowy raz na partię.

Note

Tożsamość jest jedną z wbudowanych wartości metadanych , które są przypisane do każdego elementu podczas tworzenia. Odnosi się do wartości atrybutu include w elemencie— Item innymi słowy, ścieżki i nazwy pliku elementu.

W tym przypadku, ponieważ nigdy nie powinno być więcej niż jeden element o tej samej ścieżce i nazwie pliku, firma Microsoft pracuje nad rozmiarem partii. Element docelowy jest wykonywany jednokrotnie dla każdego pakietu bazy danych.

Można zobaczyć podobną notację we właściwości _cmd , która kompiluje polecenie VSDBCMD z odpowiednimi przełącznikami.

<_Cmd>"$(VsdbCmdExe)" 
   /a:Deploy 
   /cs:"%(DbPublishPackages.DatabaseConnectionString)" 
   /p:TargetDatabase=%(DbPublishPackages.TargetDatabase)             
   /manifest:"%(DbPublishPackages.FullPath)" 
   /script:"$(_CmDbScriptPath)" 
   $(_DbDeployOrScript)
</_Cmd>

W takim przypadku % (DbPublishPackages. DatabaseConnectionString) , % (DbPublishPackages. TargetDatabase) i % (DbPublishPackages. FullPath) odwołuje się do wartości metadanych kolekcji elementów DbPublishPackages . Właściwość _cmd jest używana przez zadanie exec , które wywołuje polecenie.

<Exec Command="$(_Cmd)"/>

W wyniku tej notacji zadanie exec utworzy partie na podstawie unikatowych kombinacji wartości metadanych DatabaseConnectionString, TargetDatabasei FullPath , a zadanie zostanie wykonane raz dla każdej partii. Jest to przykład tworzenia wsadowych zadań. Jednak ponieważ przetwarzanie wsadowe na poziomie docelowym zostało już podzielone z kolekcji elementów na partie pojedynczego elementu, zadanie exec zostanie uruchomione raz i tylko raz dla każdej iteracji elementu docelowego. Innymi słowy to zadanie wywołuje narzędzie VSDBCMD raz dla każdego pakietu bazy danych w rozwiązaniu.

Note

Aby uzyskać więcej informacji na temat tworzenia wsadowych obiektów docelowych i zadań, zobacz Tworzenie wsadoweprogramu MSBuild, metadane elementu w docelowej partiii metadane elementu w ramach zadań wsadowych.

Element docelowy PublishWebPackages

W tym momencie został wywołany element docelowy BuildProjects , który generuje pakiet wdrożeniowy sieci Web dla każdego projektu w przykładowym rozwiązaniu. Towarzyszący każdemu pakietowi jest plik Deploy. cmd zawierający polecenia MSDeploy. exe wymagane do wdrożenia pakietu w środowisku docelowym oraz plik SetParameters. XML , który określa niezbędne szczegóły środowiska docelowego. Został również wywołany element docelowy GatherPackagesForPublishing , który generuje kolekcję elementów zawierającą pliki Deploy. cmd , które Cię interesują. Zasadniczo obiekt docelowy PublishWebPackages wykonuje następujące funkcje:

  • Służy do manipulowania plikiem SetParameters. XML każdego pakietu, aby zawierała poprawne szczegóły dotyczące środowiska docelowego przy użyciu zadania XmlPoke — .
  • Wywołuje plik Deploy. cmd dla każdego pakietu przy użyciu odpowiednich przełączników.

Tak samo jak element docelowy PublishDbPackages , obiekt docelowy PublishWebPackages używa docelowej partii, aby upewnić się, że element docelowy jest wykonywany raz dla każdego pakietu sieci Web.

<Target Name="PublishWebPackages" Outputs="%(PublishPackages.Identity)">

W obszarze docelowym zadanie exec służy do uruchamiania pliku Deploy. cmd dla każdego pakietu sieci Web.

<PropertyGroup>
   <_Cmd>
      %(PublishPackages.FullPath) 
      $(_WhatifSwitch) 
      /M:$(MSDeployComputerName) 
      %(PublishPackages.AdditionalMSDeployParameters)
   </_Cmd>
</PropertyGroup>
<Exec Command="$(_Cmd)"/>

Aby uzyskać więcej informacji na temat konfigurowania wdrożenia pakietów sieci Web, zobacz Kompilowanie i pakowanie projektów aplikacji sieci Web.

Podsumowanie

W tym temacie przedstawiono Przewodnik dotyczący sposobu, w jaki podzielone pliki projektu są używane do kontrolowania procesu kompilowania i wdrażania, od początku do końca dla przykładowego rozwiązania Contact Manager. Korzystając z tej metody, można uruchamiać złożone wdrożenia w skali korporacyjnej w jednym powtarzalnym kroku, po prostu uruchamiając plik poleceń specyficzny dla środowiska.

Dalsze informacje

Aby uzyskać bardziej szczegółowe wprowadzenie do plików projektu i WPP, zobacz wewnątrz Microsoft Build Engine: korzystanie z programu MSBuild i Team Foundation Build przez Sayed Ibrahim Hashimi i William BARTHOLOMEW, ISBN: 978-0-7356-4524-0.