Grundlegendes zur Projektdatei

von Jason Lee

Microsoft-Build-Engine -Projektdateien (MSBuild) stehen im Mittelpunkt des Build- und Bereitstellungsprozesses. Dieses Thema beginnt mit einer konzeptionellen Übersicht über MSBuild und die Projektdatei. Es beschreibt die wichtigsten Komponenten, auf die Sie stoßen, wenn Sie mit Projektdateien arbeiten, und es funktioniert anhand eines Beispiels, wie Sie Projektdateien verwenden können, um reale Anwendungen bereitzustellen.

Sie lernen Folgendes:

• Verwendung von MSBuild-Projektdateien zum Erstellen von Projekten
• Wie MSBuild in Bereitstellungstechnologien integriert wird, z. B. das Webbereitstellungstool für Internetinformationsdienste (IIS) (Web Deploy).
• Hier erfahren Sie, wie Sie die wichtigsten Komponenten einer Projektdatei verstehen.
• Verwenden von Projektdateien zum Erstellen und Bereitstellen komplexer Anwendungen

MSBuild und die Projektdatei

Wenn Sie Projektmappen in Visual Studio erstellen, verwendet Visual Studio MSBuild, um jedes Projekt in Ihrer Projektmappe zu erstellen. Jedes Visual Studio-Projekt enthält eine MSBuild-Projektdatei mit einer Dateierweiterung, die den Typ des Projekts widerspiegelt, z. B. ein C#-Projekt (CSPROJ), ein Visual Basic.NET-Projekt (VBPROJ) oder ein Datenbankprojekt (DBPROJ). Um ein Projekt zu erstellen, muss MSBuild die dem Projekt zugeordnete Projektdatei verarbeiten. Die Projektdatei ist ein XML-Dokument, das alle Informationen und Anweisungen enthält, die MSBuild zum Erstellen Ihres Projekts benötigt, z. B. den einzuschließenden Inhalt, die Plattformanforderungen, Versionsinformationen, Webserver- oder Datenbankservereinstellungen und die auszuführenden Aufgaben.

MSBuild-Projektdateien basieren auf dem MSBuild-XML-Schema, und daher ist der Buildprozess vollständig offen und transparent. Darüber hinaus müssen Sie Visual Studio nicht installieren, um die MSBuild-Engine verwenden zu können. Die ausführbare MSBuild.exe ist Teil des .NET Framework, und Sie können sie über eine Eingabeaufforderung ausführen. Als Entwickler können Sie ihre eigenen MSBuild-Projektdateien mithilfe des MSBuild-XML-Schemas erstellen, um eine differenzierte und differenzierte Kontrolle darüber zu erzwingen, wie Ihre Projekte erstellt und bereitgestellt werden. Diese benutzerdefinierten Projektdateien funktionieren genauso wie die Projektdateien, die Visual Studio automatisch generiert.

Hinweis

Sie können MSBuild-Projektdateien auch mit dem Team Build-Dienst in Team Foundation Server (TFS) verwenden. Beispielsweise können Sie Projektdateien in CI-Szenarien (Continuous Integration) verwenden, um die Bereitstellung in einer Testumgebung zu automatisieren, wenn neuer Code eingecheckt wird. Weitere Informationen finden Sie unter Konfigurieren von Team Foundation Server für die automatisierte Webbereitstellung.

Benennungskonventionen für Projektdateien

Wenn Sie Ihre eigenen Projektdateien erstellen, können Sie eine beliebige Dateierweiterung verwenden. Damit Ihre Lösungen für andere leichter verständlich sind, sollten Sie jedoch die folgenden allgemeinen Konventionen verwenden:

• Verwenden Sie die Erweiterung .proj, wenn Sie eine Projektdatei erstellen, die Projekte erstellt.
• Verwenden Sie die Erweiterung .targets, wenn Sie eine wiederverwendbare Projektdatei zum Importieren in andere Projektdateien erstellen. Dateien mit der Erweiterung .targets erstellen in der Regel nichts selbst, sie enthalten lediglich Anweisungen, die Sie in Ihre PROJ-Dateien importieren können.

Integration in Bereitstellungstechnologien

Wenn Sie in Visual Studio 2010 mit Webanwendungen wie ASP.NET Webanwendungen und ASP.NET MVC-Webanwendungen gearbeitet haben, wissen Sie, dass diese Projekte integrierte Unterstützung für das Packen und Bereitstellen der Webanwendung in einer Zielumgebung enthalten. Die Eigenschaftenseiten für diese Projekte enthalten die Registerkarten Package/Publish Web und Package/Publish SQL , mit denen Sie konfigurieren können, wie die Komponenten Ihrer Anwendung verpackt und bereitgestellt werden. Hier wird die Registerkarte Paket/Web veröffentlichen angezeigt:

Die zugrunde liegende Technologie hinter diesen Funktionen wird als Web Publishing Pipeline (WPP) bezeichnet. Das WPP vereint im Wesentlichen MSBuild und Web Deploy , um einen vollständigen Build-, Paket- und Bereitstellungsprozess für Ihre Webanwendungen bereitzustellen.

Die gute Nachricht ist, dass Sie die Integrationspunkte nutzen können, die das WPP bereitstellt, wenn Sie benutzerdefinierte Projektdateien für Webprojekte erstellen. Sie können Bereitstellungsanweisungen in Ihre Projektdatei einfügen, mit der Sie Ihre Projekte erstellen, Webbereitstellungspakete erstellen und diese Pakete über eine einzelne Projektdatei und einen einzigen Aufruf von MSBuild auf Remoteservern installieren können. Sie können auch alle anderen ausführbaren Dateien als Teil Ihres Buildprozesses aufrufen. Sie können beispielsweise das Befehlszeilentool VSDBCMD.exe ausführen, um eine Datenbank aus einer Schemadatei bereitzustellen. Im Verlauf dieses Themas erfahren Sie, wie Sie diese Funktionen nutzen können, um die Anforderungen Ihrer Unternehmensbereitstellungsszenarien zu erfüllen.

Hinweis

Weitere Informationen zur Funktionsweise des Bereitstellungsprozesses von Webanwendungen finden Sie unter ASP.NET Web Application Project Deployment Overview ( Übersicht über die Bereitstellung von Webanwendungsprojekten).

Die Anatomie einer Projektdatei

Bevor Sie sich den Buildprozess genauer ansehen, lohnt es sich, sich mit der grundlegenden Struktur einer MSBuild-Projektdatei vertraut zu machen. Dieser Abschnitt bietet eine Übersicht über die gängigsten Elemente, die beim Überprüfen, Bearbeiten oder Erstellen einer Projektdatei auftreten. Insbesondere lernen Sie Folgendes:

• Verwenden von Eigenschaften zum Verwalten von Variablen für den Buildprozess.
• Verwenden von Elementen zum Identifizieren der Eingaben für den Buildprozess, z. B. Codedateien.
• Verwenden von Zielen und Aufgaben zum Bereitstellen von Ausführungsanweisungen für MSBuild mithilfe von Eigenschaften und Elementen , die an anderer Stelle in der Projektdatei definiert sind.

Dies zeigt die Beziehung zwischen den schlüsseln Elementen in einer MSBuild-Projektdatei:

Das Project-Element

Das Project-Element ist das Stammelement jeder Projektdatei. Zusätzlich zum Identifizieren des XML-Schemas für die Projektdatei kann das Project-Element Attribute enthalten, um die Einstiegspunkte für den Buildprozess anzugeben. In der Contact Manager-Beispiellösung gibt die Datei Publish.proj beispielsweise an, dass der Build mit dem Aufruf des Ziels FullPublish beginnen soll.

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

Eigenschaften und Bedingungen

Eine Projektdatei muss in der Regel viele verschiedene Informationen bereitstellen, um Ihre Projekte erfolgreich erstellen und bereitstellen zu können. Diese Informationen können Servernamen, Verbindungszeichenfolgen, Anmeldeinformationen, Buildkonfigurationen, Quell- und Zieldateipfade sowie alle anderen Informationen enthalten, die Sie zur Unterstützung der Anpassung einschließen möchten. In einer Projektdatei müssen Eigenschaften innerhalb eines PropertyGroup-Elements definiert werden. MSBuild-Eigenschaften bestehen aus Schlüssel-Wert-Paaren. Innerhalb des PropertyGroup-Elements definiert der Elementname den Eigenschaftsschlüssel, und der Inhalt des Elements definiert den Eigenschaftswert. Sie können beispielsweise Eigenschaften namens ServerName und ConnectionString definieren, um einen statischen Servernamen und Verbindungszeichenfolge zu speichern.

<PropertyGroup>    
   <ServerName>FABRIKAM\TEST1</ServerName>
   <ConnectionString>
     Data Source=FABRIKAM\TESTDB;InitialCatalog=ContactManager,...
   </ConnectionString>
</PropertyGroup>

Verwenden Sie zum Abrufen eines Eigenschaftswerts das Format $(PropertyName). Um beispielsweise den Wert der ServerName-Eigenschaft abzurufen, geben Sie Folgendes ein:

$(ServerName)

Hinweis

Beispiele für die Verwendung von Eigenschaftswerten finden Sie weiter unten in diesem Thema.

Das Einbetten von Informationen als statische Eigenschaften in eine Projektdatei ist nicht immer der ideale Ansatz für die Verwaltung des Buildprozesses. In vielen Szenarien sollten Sie die Informationen aus anderen Quellen abrufen oder dem Benutzer die Möglichkeit geben, die Informationen über die Eingabeaufforderung bereitzustellen. MIT MSBuild können Sie einen beliebigen Eigenschaftswert als Befehlszeilenparameter angeben. Beispielsweise könnte der Benutzer einen Wert für ServerName angeben, wenn er MSBuild.exe über die Befehlszeile ausführt.

msbuild.exe Publish.proj /p:ServerName=FABRIKAM\TESTWEB1

Hinweis

Weitere Informationen zu den Argumenten und Schaltern, die Sie mit MSBuild.exe verwenden können, finden Sie unter MSBuild-Befehlszeilenreferenz.

Sie können dieselbe Eigenschaftensyntax verwenden, um die Werte von Umgebungsvariablen und integrierten Projekteigenschaften abzurufen. Viele häufig verwendete Eigenschaften werden für Sie definiert, und Sie können sie in Ihren Projektdateien verwenden, indem Sie den relevanten Parameternamen einschließen. Zum Abrufen der aktuellen Projektplattform , z. B. x86 oder AnyCpu, können Sie den $(Platform) -Eigenschaftsverweis in Ihre Projektdatei einschließen. Weitere Informationen finden Sie unter Makros für Buildbefehle und -eigenschaften, Allgemeine MSBuild-Projekteigenschaften und reservierte Eigenschaften.

Eigenschaften werden häufig in Verbindung mit Bedingungen verwendet. Die meisten MSBuild-Elemente unterstützen das Condition-Attribut , mit dem Sie die Kriterien angeben können, nach denen MSBuild das Element auswerten soll. Betrachten Sie beispielsweise diese Eigenschaftsdefinition:

<PropertyGroup>
   <OutputRoot Condition=" '$(OutputRoot)'=='' ">..\Publish\Out\</OutputRoot>
   ...
</PropertyGroup>

Wenn MSBuild diese Eigenschaftsdefinition verarbeitet, wird zuerst überprüft, ob ein $(OutputRoot)- Eigenschaftswert verfügbar ist. Wenn der Eigenschaftswert leer ist (d. h., der Benutzer hat keinen Wert für diese Eigenschaft angegeben), wird die Bedingung auf true ausgewertet, und der Eigenschaftswert wird auf festgelegt. \Publish\Out. Wenn der Benutzer einen Wert für diese Eigenschaft angegeben hat, wird die Bedingung als false ausgewertet, und der wert der statischen Eigenschaft wird nicht verwendet.

Weitere Informationen zu den verschiedenen Möglichkeiten zum Angeben von Bedingungen finden Sie unter MSBuild-Bedingungen.

Elemente und Elementgruppen

Eine der wichtigen Rollen der Projektdatei besteht darin, die Eingaben für den Buildprozess zu definieren. In der Regel handelt es sich bei diesen Eingaben um Dateien– Codedateien, Konfigurationsdateien, Befehlsdateien und alle anderen Dateien, die Sie im Rahmen des Buildprozesses verarbeiten oder kopieren müssen. Im MSBuild-Projektschema werden diese Eingaben durch Item-Elemente dargestellt. In einer Projektdatei müssen Elemente in einem ItemGroup-Element definiert werden. Genau wie Property-Elemente können Sie ein Item-Element beliebig benennen. Sie müssen jedoch ein Include-Attribut angeben, um die Datei oder den Wildcard zu identifizieren, die das Element darstellt.

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

Indem Sie mehrere Item-Elemente mit demselben Namen angeben, erstellen Sie effektiv eine benannte Liste von Ressourcen. Eine gute Möglichkeit, dies in Aktion zu sehen, besteht darin, einen Blick in eine der Projektdateien zu werfen, die Visual Studio erstellt. Die Datei ContactManager.Mvc.csproj in der Beispiellösung enthält beispielsweise viele Elementgruppen mit jeweils mehreren identisch benannten Item-Elementen .

<ItemGroup>
   <Reference Include="Microsoft.CSharp" />
   <Reference Include="System.Runtime.Serialization" />
   <Reference Include="System.ServiceModel" />
   ...
</ItemGroup>
<ItemGroup>
   <Compile Include="Controllers\AccountController.cs" />
   <Compile Include="Controllers\ContactsController.cs" />
   <Compile Include="Controllers\HomeController.cs" />
   ...
</ItemGroup>
<ItemGroup>
   <Content Include="Content\Custom.css" />
   <Content Include="CreateDatabase.sql" />
   <Content Include="DropDatabase.sql" />
   ...
</ItemGroup>

Auf diese Weise weist die Projektdatei MSBuild an, Listen von Dateien zu erstellen, die auf die gleiche Weise verarbeitet werden müssen. Die Verweisliste enthält Assemblys, die für einen erfolgreichen Build vorhanden sein müssen, die Liste Kompilieren enthält Codedateien, die kompiliert werden müssen, und die Inhaltsliste enthält Ressourcen, die unverändert kopiert werden müssen. Weiter unten in diesem Thema wird erläutert, wie der Buildprozess auf diese Elemente verweist und verwendet.

Item-Elemente können auch untergeordnete ItemMetadata-Elemente enthalten. Dies sind benutzerdefinierte Schlüssel-Wert-Paare und stellen im Wesentlichen Eigenschaften dar, die für dieses Element spezifisch sind. Viele der Compile-Elementelemente in der Projektdatei enthalten beispielsweise untergeordnete DependentUpon-Elemente.

<Compile Include="Global.asax.cs">
   <DependentUpon>Global.asax</DependentUpon>
</Compile>

Hinweis

Zusätzlich zu den vom Benutzer erstellten Elementmetadaten werden allen Elementen bei der Erstellung verschiedene allgemeine Metadaten zugewiesen. Weitere Informationen finden Sie unter Bekannte Elementmetadaten.

Sie können ItemGroup-Elemente innerhalb des Project-Elements auf Stammebene oder innerhalb bestimmter Target-Elemente erstellen. ItemGroup-Elemente unterstützen auch Condition-Attribute , mit denen Sie die Eingaben an den Buildprozess an Bedingungen anpassen können, z. B. die Projektkonfiguration oder die Plattform.

Ziele und Aufgaben

Im MSBuild-Schema stellt ein Task-Element eine einzelne Buildanweisung (oder aufgabe) dar. MSBuild umfasst eine Vielzahl vordefinierter Aufgaben. Beispiel:

• Der Kopiertask kopiert Dateien an einen neuen Speicherort.
• Der Csc-Task ruft den Visual C#-Compiler auf.
• Der Vbc-Task ruft den Visual Basic-Compiler auf.
• Der Exec-Task führt ein angegebenes Programm aus.
• Der Task "Nachricht " schreibt eine Nachricht in eine Protokollierung.

Hinweis

Ausführliche Informationen zu den Aufgaben, die sofort verfügbar sind, finden Sie unter MSBuild-Aufgabenreferenz. Weitere Informationen zu Aufgaben, einschließlich der Erstellung eigener benutzerdefinierter Aufgaben, finden Sie unter MSBuild-Aufgaben.

Aufgaben müssen immer in Zielelementen enthalten sein. Ein Target-Element ist eine Gruppe von mindestens einer Aufgabe, die sequenziell ausgeführt wird, und eine Projektdatei kann mehrere Ziele enthalten. Wenn Sie eine Aufgabe oder eine Reihe von Aufgaben ausführen möchten, rufen Sie das Ziel auf, das sie enthält. Angenommen, Sie verfügen über eine einfache Projektdatei, die eine Nachricht protokolliert.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name="LogMessage">
      <Message Text="Hello world!" />
   </Target>
</Project>

Sie können das Ziel über die Befehlszeile aufrufen, indem Sie den Schalter /t verwenden, um das Ziel anzugeben.

msbuild.exe Publish.proj /t:LogMessage

Alternativ können Sie dem Project-Element ein DefaultTargets-Attribut hinzufügen, um die Ziele anzugeben, die Sie aufrufen möchten.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" 
         DefaultTargets="FullPublish">
   <Target Name="LogMessage">
      <Message Text="Hello world!" />
   </Target>
</Project>

In diesem Fall müssen Sie das Ziel nicht über die Befehlszeile angeben. Sie können einfach die Projektdatei angeben, und MSBuild ruft das FullPublish-Ziel für Sie auf.

msbuild.exe Publish.proj

Sowohl Ziele als auch Aufgaben können Bedingungsattribute enthalten. Daher können Sie ganze Ziele oder einzelne Aufgaben weglassen, wenn bestimmte Bedingungen erfüllt sind.

Im Allgemeinen müssen Sie beim Erstellen nützlicher Aufgaben und Ziele auf die Eigenschaften und Elemente verweisen, die Sie an anderer Stelle in der Projektdatei definiert haben:

• Um einen Eigenschaftswert zu verwenden, geben Sie $(PropertyName) ein, wobei PropertyName der Name des Property-Elements oder der Name des Parameters ist.
• Um ein Element zu verwenden, geben Sie @(ItemName) ein, wobei ItemName der Name des Item-Elements ist.

Hinweis

Denken Sie daran, dass Sie eine Liste erstellen, wenn Sie mehrere Elemente mit demselben Namen erstellen. Wenn Sie hingegen mehrere Eigenschaften mit demselben Namen erstellen, überschreibt der von Ihnen bereitgestellte letzte Eigenschaftswert alle vorherigen Eigenschaften mit demselben Namen. Eine Eigenschaft kann nur einen einzelnen Wert enthalten.

Sehen Sie sich beispielsweise in der Datei Publish.proj in der Beispiellösung das BuildProjects-Ziel an.

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

In diesem Beispiel können Sie die folgenden wichtigen Punkte beachten:

• Wenn der BuildingInTeamBuild-Parameter angegeben ist und den Wert true aufweist, wird keine der Aufgaben innerhalb dieses Ziels ausgeführt.

• Das Ziel enthält eine einzelne instance des MSBuild-Tasks. Mit dieser Aufgabe können Sie andere MSBuild-Projekte erstellen.

• Das ProjectsToBuild-Element wird an die Aufgabe übergeben. Dieses Element kann eine Liste von Projekt- oder Projektmappendateien darstellen, die alle durch ProjectsToBuild-Elementelemente innerhalb einer Elementgruppe definiert sind. In diesem Fall verweist das ProjectsToBuild-Element auf eine einzelne Projektmappendatei.

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

• Die an den MSBuild-Task übergebenen Eigenschaftenwerte umfassen Parameter mit dem Namen OutputRoot und Configuration. Diese werden auf Parameterwerte festgelegt, sofern sie angegeben werden, oder auf statische Eigenschaftswerte, falls nicht.

  <PropertyGroup>
     ... 
     <Configuration Condition=" '$(Configuration)'=='' ">Release
     </Configuration>
     <OutputRoot Condition=" '$(OutputRoot)'=='' ">..\Publish\Out\
     </OutputRoot>
     ...
  </PropertyGroup>
  

Sie können auch sehen, dass der MSBuild-Task ein Ziel namens Build aufruft. Dies ist eines von mehreren integrierten Zielen, die häufig in Visual Studio-Projektdateien verwendet werden und ihnen in Ihren benutzerdefinierten Projektdateien wie Build, Clean, Rebuild und Publish zur Verfügung stehen. Weitere Informationen zur Verwendung von Zielen und Aufgaben zum Steuern des Buildprozesses und insbesondere zur MSBuild-Aufgabe finden Sie weiter unten in diesem Thema.

Hinweis

Weitere Informationen zu Zielen finden Sie unter MSBuild-Ziele.

Aufteilen von Projektdateien zur Unterstützung mehrerer Umgebungen

Angenommen, Sie möchten eine Lösung in mehreren Umgebungen bereitstellen können, z. B. Testserver, Stagingplattformen und Produktionsumgebungen. Die Konfiguration kann zwischen diesen Umgebungen erheblich variieren – nicht nur in Bezug auf Servernamen, Verbindungszeichenfolgen usw., sondern auch potenziell in Bezug auf Anmeldeinformationen, Sicherheitseinstellungen und viele andere Faktoren. Wenn Sie dies regelmäßig tun müssen, ist es nicht wirklich sinnvoll, mehrere Eigenschaften in Ihrer Projektdatei jedes Mal zu bearbeiten, wenn Sie die Zielumgebung wechseln. Es ist auch keine ideale Lösung, eine endlose Liste von Eigenschaftswerten für den Buildprozess bereitzustellen.

Glücklicherweise gibt es eine Alternative. MIT MSBuild können Sie Ihre Buildkonfiguration auf mehrere Projektdateien aufteilen. Um zu sehen, wie dies funktioniert, beachten Sie in der Beispiellösung, dass es zwei benutzerdefinierte Projektdateien gibt:

• Publish.proj, die Eigenschaften, Elemente und Ziele enthält, die allen Umgebungen gemeinsam sind.
• Env-Dev.proj, die Eigenschaften enthält, die für eine Entwicklerumgebung spezifisch sind.

Beachten Sie nun, dass die Datei Publish.proj ein Import-Element direkt unter dem öffnenden Project-Tag enthält.

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

Das Import-Element wird verwendet, um den Inhalt einer anderen MSBuild-Projektdatei in die aktuelle MSBuild-Projektdatei zu importieren. In diesem Fall stellt der Parameter TargetEnvPropsFile den Dateinamen der Projektdatei bereit, die Sie importieren möchten. Sie können einen Wert für diesen Parameter angeben, wenn Sie MSBuild ausführen.

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

Dadurch werden die Inhalte der beiden Dateien effektiv in einer einzelnen Projektdatei zusammengeführt. Mit diesem Ansatz können Sie eine Projektdatei erstellen, die Ihre universelle Buildkonfiguration und mehrere zusätzliche Projektdateien mit umgebungsspezifischen Eigenschaften enthält. Daher können Sie ihre Lösung einfach in einer anderen Umgebung bereitstellen, indem Sie einfach einen Befehl mit einem anderen Parameterwert ausführen.

Das Aufteilen Ihrer Projektdateien auf diese Weise ist eine bewährte Methode. Es ermöglicht Entwicklern die Bereitstellung in mehreren Umgebungen, indem sie einen einzelnen Befehl ausführen, während gleichzeitig die Duplizierung von universellen Buildeigenschaften über mehrere Projektdateien hinweg vermieden wird.

Hinweis

Eine Anleitung zum Anpassen der umgebungsspezifischen Projektdateien für Ihre eigenen Serverumgebungen finden Sie unter Konfigurieren von Bereitstellungseigenschaften für eine Zielumgebung.

Zusammenfassung

Dieses Thema enthält eine allgemeine Einführung in MSBuild-Projektdateien und erläuterte, wie Sie Ihre eigenen benutzerdefinierten Projektdateien erstellen können, um den Buildprozess zu steuern. Außerdem wurde das Konzept der Aufteilung von Projektdateien in universelle Buildanweisungen und umgebungsspezifische Buildeigenschaften eingeführt, um das Erstellen und Bereitstellen von Projekten an mehreren Zielen zu vereinfachen.

Das nächste Thema, Grundlegendes zum Buildprozess, bietet weitere Einblicke in die Verwendung von Projektdateien zum Steuern von Build und Bereitstellung, indem Sie die Bereitstellung einer Lösung mit einem realistischen Maß an Komplexität durchlaufen.

Weitere Informationen

Eine ausführlichere Einführung in Projektdateien und das WPP finden Sie unter Inside the Microsoft-Build-Engine: Using MSBuild and Team Foundation Build by Sayed Ibrahim Hashimi and William Bartholomew, ISBN: 978-0-7356-4524-0.

ZurückWeiter