Freigeben über

Erstellen einer WPF-Anwendung (WPF)

  • Artikel

Aktualisiert: Juli 2008

Windows Presentation Foundation (WPF)-Anwendungen können als .NET Framework-EXE-, -DLL-Datei oder als Kombination aus beiden Assemblytypen erstellt werden. In diesem Thema wird zunächst das Erstellen von einfachen WPF-Anwendungen über die Eingabeaufforderung veranschaulicht, bevor gezeigt wird, wie WPF die Erweiterbarkeit von Microsoft-Buildmodul (MSBuild) zum Erstellen komplexerer Anwendungen nutzt. Dieses Thema wird mit einer ausführlichen Erörterung der wesentlichen Schritte im MSBuild-Buildprozess abgeschlossen.

Dieses Thema enthält folgende Abschnitte.

  • Erstellen einer WPF-Anwendung mithilfe der Befehlszeilenkompilierung
  • Erstellen einer WPF-Anwendung mithilfe von MSBuild
  • MSBuild-Projektdateien für WPF
  • Erstellen eines MSBuild-Projekts für WPF mit Visual Studio
  • Erstellen eines MSBuild-Projekts für WPF
  • Windows Presentation Foundation-Buildpipeline
  • Unterstützung für inkrementelle Builds
  • Verwandte Abschnitte

Erstellen einer WPF-Anwendung mithilfe der Befehlszeilenkompilierung

Eine vollständig in Code geschriebene WPF-Anwendung (kein Markup) kann mit einem Befehlszeilencompiler erstellt werden. Stellen Sie sich beispielsweise eine eigenständige C# WPF-Anwendung mit den folgenden Quellcodedateien vor:

  • Anwendungsdefinitionsdatei (app.cs)

  • Fenster (mainwindow.cs)

Diese Anwendung lässt sich wie im folgenden Beispiel mithilfe des C#-Compilers (csc.exe) über eine Eingabeaufforderung erstellen:

csc.exe
  /out:WPFApplication.exe
  /target:winexe 
  app.cs mainwindow.cs 
  /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\presentationframework.dll" 
  /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\windowsbase.dll" 
  /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\presentationcore.dll"

In diesem Beispiel:

  • Der /out-Parameter gibt den Namen der erstellten ausführbaren Assembly (WPFApplication.exe) an.

  • Der /target-Parameter gibt den kompilierten Assemblytyp an (eine ausführbare Microsoft Windows-Datei).

  • Die C#-Quellcodedateien, die die Anwendung (app.cs und mainwindow.cs) bilden.

  • Der /reference-Parameter, der die Assemblys, auf die verwiesen wird, identifiziert, die die von der Anwendung verwendeten Typen implementieren.

Befehlszeilenkompilierung kann zum Erstellen von komplexeren Anwendungen verwendet werden, obwohl der Compiler WPF-Anwendungen mit Extensible Application Markup Language (XAML)-Quellcode nicht unterstützt. Darüber hinaus unterstützt die Befehlszeilenkompilierung nicht alle Buildanforderungen typischer WPF-Anwendungen, einschließlich Konfigurationsverwaltung und ClickOnce-Manifestgenerierung. Um diese und andere komplexere Buildanforderungen zu unterstützen, wird WPF mit MSBuild integriert und erweitert dieses Modul.

Tipp

Weitere Informationen zur Befehlszeilenkompilierung finden Sie unter Erstellen über die Befehlszeile mit csc.exe oder Erstellen von der Befehlszeile aus (Visual Basic).

Erstellen einer WPF-Anwendung mithilfe von MSBuild

MSBuild ist eine robuste, erweiterbare Technologie, die mit .NET Framework eingeführt wurde. Der Kern der MSBuild-Technologie wird über die in der folgenden Tabelle beschriebenen Assemblys implementiert.

Assembly

Beschreibung

Microsoft.Build.Engine.dll

Liest und verarbeitet MSBuild-Projektdateien.

Microsoft.Build.Tasks.dll

Implementiert Funktionen, die in allen MSBuild-Projekten vorkommen, z. B. Aufruf der Befehlszeilenkompilierung (beispielsweise csc.exe für C#, vbc.exe für Visual Basic).

Microsoft.Build.Utilities.dll

Macht Dienstprogrammklassen verfügbar, die MSBuild mit benutzerdefinierten Buildfunktionen erweitern.

Microsoft.Build.Framework.dll

Implementiert Schnittstellen, die definieren, wie MSBuild-Funktionalität mit dem MSBuild-Modul interagiert.

Microsoft.Build.Conversion.dll

Unterstützt Konvertierung vom Microsoft Visual Studio .NET 2002-Legacy- und Microsoft Visual Studio .NET 2003-Projektdateiformat in das Microsoft Visual Studio 2005MSBuild-Projektdateiformat.

Tipp

Weitere Informationen zu den MSBuild-Assemblys finden Sie unter MSBuild-Referenz.

MSBuild-Projektdateien für WPF

Die Assemblys, die MSBuild bilden, werden als MSBuild-Modul bezeichnet. Um Anwendungen zu erstellen, benötigt das MSBuild-Modul normalerweise folgende Informationen:

  • Verweise auf die Quellcodedatei

  • Verweise auf abhängige Assemblys

  • Konfigurationsdetails

  • Buildanforderungen

Um von MSBuild verarbeitet zu werden, werden diese Informationen in XML-Dateien gepackt, die dem benutzerdefinierten MSBuild-Schema entsprechen (siehe Referenz zum MSBuild-Projektdateischema). Solche Dateien werden als MSBuild-Projektdateien bezeichnet. Im Folgenden sehen Sie die MSBuild-Projektdatei für eine Version der WPF-Anwendung, die zu einem früheren Zeitpunkt mithilfe eines Befehlszeilencompilers und zusätzlichen Extensible Application Markup Language (XAML)-Quellcodedateien erstellt wurde.

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     <PropertyGroup>
         <AssemblyName>WPFApplication</AssemblyName>
         <OutputType>winexe</OutputType>
     </PropertyGroup>
     <ItemGroup>
         <Reference Include="System" />
         <Reference Include="WindowsBase" />
         <Reference Include="PresentationCore" />
         <Reference Include="PresentationFramework" />
     </ItemGroup>
     <ItemGroup>
         <ApplicationDefinition Include="App.xaml" />
         <Compile Include="App.xaml.cs" />
         <Page Include="MainWindow.xaml" />
         <Compile Include="MainWindow.xaml.cs" />
     </ItemGroup>
     <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
     <Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />
</Project>

In diesem Beispiel sind die Elemente enthalten, die in den meisten MSBuild-Projektdateien enthalten sind, einschließlich Project-Tag, Eigenschaften, Elemente, Ziele und Aufgaben.

Das Projektelement

Entsprechend dem MSBuild-Projektdateischema ist eine MSBuild-Projektdatei eine XML-Datei mit Project als Element der obersten Ebene:

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     ...
</Project>

Das Project-Element befindet sich dort, wo das MSBuild-Modul mit der Verarbeitung einer Projektdatei beginnt. Um die Version von MSBuild anzugeben, auf das die MSBuild-Projektdatei abzielt, wird eine entsprechende XML-Namespacedeklaration zur Verfügung gestellt.

Eigenschaften

Eigenschaften sind Variablen, mit denen MSBuild-Projekte sowohl konfiguriert als auch dem MSBuild-Modul buildrelevante Informationen zur Verfügung gestellt werden. Eigenschaften sind in PropertyGroup-Elementen enthalten, wie im folgenden Beispiel gezeigt.

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     <PropertyGroup>
         <AssemblyName>WPFApplication</AssemblyName>
         <OutputType>winexe</OutputType>
     </PropertyGroup>
     ...
</Project>

Einige Eigenschaften, z. B. AssemblyName und OutputType, sind allen Anwendungstypen gemein und werden in Gemeinsame MSBuild-Projekteigenschaften beschrieben. Die MSBuild-Eigenschaften, die für WPF spezifisch sind, werden in der folgenden Tabelle aufgelistet.

Property

Beschreibung

OutputType

Gibt den Typ der erstellten Assembly an und entspricht einem der folgenden Werte:

  • winexe: Erstellt eine ausführbare Assembly (.exe). Eigenständige Anwendungen und XBAPs werden mit diesem Ausgabetyp konfiguriert.

  • library: Erstellt eine Bibliotheksassembly (.dll). Freigegebene Assemblys und benutzerdefinierte Steuerelementbibliotheken werden mit diesem Ausgabetyp konfiguriert.

HostInBrowser

Gibt an, ob eine WPF-Anwendung in einem Browser gehostet wird und entspricht einem der folgenden Werte:

  • true: Erstellt eine XBAP, die eine Hauptanwendungsassembly (.exe), ein Bereitstellungsmanifest (applicationName.xbap) und ein Anwendungsmanifest (applicationName.exe.manifest) enthält.

  • false: Erstellt eine eigenständige Anwendung.

Wenn HostInBrowser true ist, muss OutputType winexe sein.

Install

Gibt an, ob eine XBAP auf dem Client installiert ist. Install kann true oder false sein und hat den entgegengesetzten Wert von HostInBrowser.

GenerateManifests

Gibt an, ob eine eigenständige Anwendung mithilfe der ClickOnce-Bereitstellung veröffentlicht wurde und entspricht einem der folgenden Werte:

  • true: Erstellt die ausführbare Hauptdatei der Anwendung, ein Bereitstellungsmanifest (applicationName.application) und ein Anwendungsmanifest (applicationName.exe.manifest).

  • false: Erstellt lediglich die ausführbare Datei der Anwendung (.exe).

GenerateManifests wird nur verwendet, wenn Install über den Wert true verfügt.

UICulture

Gibt das Gebietsschema an, für das die Assembly erstellt wird. Wenn diese Option angegeben wird, werden Dateien, die als Resource-Projektelemente und sprachspezifische Ressourcen deklariert sind, in eine Satellitenassembly für das gewünschte Gebietsschema kompiliert. Andererseits wird sprachneutraler Inhalt in die Hauptassembly kompiliert. Standardmäßig werden Anwendungen nicht lokalisiert, und Ressourcendateien werden infolgedessen in die Hauptassembly eingebettet.

Tipp

Wenn UICulture festgelegt wird, muss die neutrale Ressourcensprache mit NeutralResourcesLanguageAttribute angegeben werden. Dieses Attribut muss der AssemblyInfo-Datei einer WPF-Anwendung hinzugefügt werden.

Elemente

Elemente sind MSBuild-Eingaben, die während des Buildprozesses vom MSBuild-Modul verarbeitet werden. Elemente sind in einem ItemGroup-Element enthalten.

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     ...
     <ItemGroup>
         <Reference Include="System" />
         <Reference Include="WindowsBase" />
         <Reference Include="PresentationCore" />
         <Reference Include="PresentationFramework" />
     </ItemGroup>
     <ItemGroup>
         <ApplicationDefinition Include="App.xaml" />
         <Compile Include="App.xaml.cs" />
         <Page Include="MainWindow.xaml" />
         <Compile Include="MainWindow.xaml.cs" />
     </ItemGroup>
     ...
</Project>

Ein Elementtyp kann mit Metadaten konfiguriert werden. Im vorangehenden Beispiel wurden Assemblyverweise als Reference-Elemente konfiguriert, und Quellcodedateien werden als Compile-Elemente konfiguriert. Das Reference-Element und das Compile-Element sind in allen .NET Framework-Anwendungen enthalten und werden unter Gemeinsame MSBuild-Projektelemente genauer beschrieben.

Die WPF-spezifischen MSBuild-Elemente werden in der folgenden Tabelle aufgelistet.

Property

Beschreibung

ApplicationDefinition

Gibt die XAML-Markupdatei an, die die Anwendungsdefinition enthält (eine XAML-Markupdatei, deren Stammelement Application ist). ApplicationDefinition ist erforderlich, wenn Install true und OutputType winexe ist. Eine WPF-Anwendung und folglich auch ein MSBuild-Projekt können nur eine ApplicationDefinition haben.

Page

Gibt eine XAML-Markupdatei an, deren Inhalt in ein Binärformat konvertiert und in eine Assembly kompiliert wurde. Page-Elemente werden normalerweise in Verbindung mit einer Code-Behind-Klasse implementiert.

Die gebräuchlichsten Page-Elemente sind XAML-Dateien, deren Elemente der obersten Ebene eines der folgenden Elemente darstellen:

Resource

Gibt eine Ressourcendatei an, die in eine Anwendungsassembly kompiliert wird. Wie bereits erwähnt, verarbeitet UICulture Resource-Elemente.

Content

Gibt eine Inhaltsdatei an, die mit einer Anwendung verteilt wird. Metadaten zur Beschreibung der Inhaltsdatei werden (mit AssemblyAssociatedContentFileAttribute) in die Anwendung kompiliert.

SplashScreen

Identifiziert eine Bilddatei, die für das Startfenster der Anwendung verwendet wird. Die PresentationBuildTasks-Assembly generiert Code in App.g.cs oder Application.g.vb, mit dem eine SplashScreen-Instanz erstellt wird, und zeigt sie während des Ladens der Anwendung an. Dieses Element ist verfügbar in Visual Studio 2008 SP1.

Ziele

Ziele bestimmen, wie Projekte erstellt werden. Sie hängen sowohl von Eigenschaften als auch von Elementen ab. Eine WPF-Anwendung muss ein sprachspezifisches Ziel und ein WPF-spezifisches Ziel haben.

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     ...
     <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
     <Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />
</Project>

Ziele sind separate Dateien, die mit der Erweiterung .targets enden. Die in .NET Framework enthaltenen Zieldateien werden an folgendem Speicherort installiert:

%WINDIR%\Microsoft.NET\Framework\vX.X.X

Das sprachspezifische Ziel erstellt den sprachspezifischen Quellcode. Das sprachspezifische Ziel für C# ist Microsoft.CSharp.targets und Microsoft.VisualBasic.targets für  Visual Basic. Beide Ziele werden vom Ziel Microsoft.Common.targets abgeleitet und erweitern dieses. Dieses Ziel übernimmt den größten Teil der allgemeinen, sprachunabhängigen Erstellung. Weitere Informationen zu allgemeinen und sprachspezifischen MSBuild-Zielen finden Sie unter .Targets-Dateien von MSBuild.

WPF-spezifische Erstellung wird durch das Ziel Microsoft.WinFX.targets ausgeführt. Diese Arbeit umfasst XAML-Markupkompilierung, Manifestgenerierung für XBAP-Anwendungen und das Verarbeiten von WPF-Ressourcen- und -Inhaltsdateien.

Aufgaben

Eine Aufgabe ist eine Klasse, die einen bestimmten Buildvorgang ausführt. Es werden eine oder mehrere Aufgaben durch Ziele kombiniert, um einen Buildprozess zu definieren. Wenn MSBuild ein Ziel verarbeitet, führt es die Aufgaben aus, die im Ziel enthalten sind. Die von allgemeinen sprachspezifischen Zielen verwendeten Aufgaben werden durch die Assembly Microsoft.Build.Tasks implementiert. Die Aufgaben, die für WPF spezifisch sind, werden durch die Assembly PresentationBuildTasks implementiert.

Ziele stellen die Unterstützung zur Erstellung aller WPF-Standardanwendungen bereit. Aufgaben können auch anders kombiniert werden, um benutzerdefiniertes Buildverhalten zu implementieren. Die folgende MSBuild GetWinFXPath-Aufgabe wird beispielsweise dazu verwendet, den systemeigenen Pfad zur .NET Framework-Laufzeit zu ermitteln. Das hängt auch davon ab, ob die Aufgabe auf eine 64-Bit-Prozessor ausgeführt wird:

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     <UsingTask 
         TaskName="Microsoft.Build.Tasks.Windows.GetWinFXPath" 
         AssemblyFile="C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationBuildTasks.dll" />
     <Target Name="GetWinFXPathTask">
         <GetWinFXPath
             WinFXNativePath="c:\DOTNet3Native" 
             WinFXWowPath="c:\DOTNet3WowNative" />
     </Target>
     <Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />
</Project>

Weitere Informationen zu allgemeinen MSBuild-Aufgaben finden Sie unter Referenz zu MSBuild-Aufgaben.

MSBuild-Projektbeispiele für Windows Presentation Foundation

Das Windows Software Development Kit (SDK) enthält mehrere Beispiele für MSBuild-Projektdateien für die gebräuchlichsten WPF-Anwendungstypen:

Erstellen eines MSBuild-Projekts für WPF mit Visual Studio

Visual Studio generiert MSBuild-Projektdateien automatisch, wenn neue WPF-Anwendungen mit den Visual Studio-Projektvorlagen erstellt werden. Die Projektvorlage der WPF-Anwendung erzeugt beispielsweise die folgende Projektdatei (für C#):

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>9.0.20726</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{E0EA3EBA-718C-4122-B20C-EB97B7DC6604}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>WpfApplication1</RootNamespace>
    <AssemblyName>WpfApplication1</AssemblyName>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <ProjectTypeGuids>
      {60dc8134-eba5-43b8-bcc9-bb4bc16c2548};
      {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
    </ProjectTypeGuids>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Core">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Xml.Linq">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Data.DataSetExtensions">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="WindowsBase" />
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
  </ItemGroup>
  <ItemGroup>
    <ApplicationDefinition Include="App.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </ApplicationDefinition>
    <Page Include="Window1.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </Page>
    <Compile Include="App.xaml.cs">
      <DependentUpon>App.xaml</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
    <Compile Include="Window1.xaml.cs">
      <DependentUpon>Window1.xaml</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Properties\AssemblyInfo.cs">
      <SubType>Code</SubType>
    </Compile>
    <Compile Include="Properties\Resources.Designer.cs">
      <AutoGen>True</AutoGen>
      <DesignTime>True</DesignTime>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
    <Compile Include="Properties\Settings.Designer.cs">
      <AutoGen>True</AutoGen>
      <DependentUpon>Settings.settings</DependentUpon>
      <DesignTimeSharedInput>True</DesignTimeSharedInput>
    </Compile>
    <EmbeddedResource Include="Properties\Resources.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>Resources.Designer.cs</LastGenOutput>
      <SubType>Designer</SubType>
    </EmbeddedResource>
    <None Include="Properties\Settings.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
      <LastGenOutput>Settings.Designer.cs</LastGenOutput>
    </None>
    <AppDesigner Include="Properties\" />
  </ItemGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
</Project>

Der Name der generierten MSBuild-Projektdateierweiterung integriert die Quellcodesprache:

  • Für C#-Projekte lautet die Erweiterung .csproj.

  • Für Visual Basic-Projekte lautet die Erweiterung **.**vbproj.

Die Projektdatei ist größer als die vorherigen Beispiele. Dies ist zum Teil auf mehrere zusätzliche Eigenschaften zurückzuführen. Diese zusätzlichen Informationen sind allerdings Visual Studio-spezifisch und umfassen Folgendes:

  • Projektkonfiguration

  • Buildkonfiguration

  • Zuordnung der Quellcodedatei

  • Standardprojekteigenschaft, Ressource und Verwaltung von Einstellungen

Projektkonfiguration

Die Details zur Projektkonfiguration umfassen einen eindeutigen Bezeichner für das Projekt, einen eindeutigen Bezeichner für den Projekttyp und verschiedene Daten, die die .NET Framework- und Visual Studio-Version identifizieren:

<Project 
  ToolsVersion="3.5"
  DefaultTargets="Build"
  xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <ProductVersion>9.0.20726</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{E0EA3EBA-718C-4122-B20C-EB97B7DC6604}</ProjectGuid>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
    <ProjectTypeGuids>
      {60dc8134-eba5-43b8-bcc9-bb4bc16c2548};
      {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
    </ProjectTypeGuids>
  </PropertyGroup>
  ...
</Project>

Buildkonfiguration

Ein standardmäßiges Visual Studio-Projekt hat zwei Buildkonfigurationen: Debug und Release (siehe Buildkonfigurationen). In einer MSBuild-Projektdatei werden diese mit Eigenschaften konfiguriert:

<Project ... >
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">
      Debug
    </Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>WpfApplication1</RootNamespace>
    <AssemblyName>WpfApplication1</AssemblyName>
    <FileAlignment>512</FileAlignment>
    <WarningLevel>4</WarningLevel>
    ...
  </PropertyGroup>
  ...
</Project>

Die aktuelle Buildkonfiguration wird durch die Configuration-Eigenschaft angegeben:

<Project ... >
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">
      Debug
    </Configuration>
    ...
  </PropertyGroup>
  ...
</Project>

Zuordnung der Quellcodedatei

Visual Studio verwaltet eine Zuordnung zwischen verknüpften Quellcodedateien, z. B. Markup- und Code-Behind-Dateien. Infolgedessen kann Visual Studio die Zuordnung im Fenster Visual Studio Projektmappen-Explorer visuell darstellen:

Projektmappen-Explorer-Bildschirmabbildung

Die Zuordnung zwischen verknüpften Quellcodedateien wird mit DependentUpon-Metadaten und SubType-Metadaten durchgeführt:

<Project ... >
  ...
  <ItemGroup>
    <ApplicationDefinition Include="App.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </ApplicationDefinition>
    <Page Include="Window1.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </Page>
    <Compile Include="App.xaml.cs">
      <DependentUpon>App.xaml</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
    <Compile Include="Window1.xaml.cs">
      <DependentUpon>Window1.xaml</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
  </ItemGroup>
  ...
</Project>

In diesem Projekt wird App.xaml (Markup) mit App.xaml.cs (Code-Behind) verknüpft, und Window1.xaml (Markup) wird mit Window1.xaml.cs (Code-Behind) verknüpft.

Standardprojekteigenschaft, Ressource und Verwaltung von Einstellungen

Mit Visual Studio können Sie die Eigenschaften eines Visual Studio-Projekts visuell bearbeiten. Die meisten dieser Eigenschaften wirken sich auf den Buildprozess aus und werden in der Visual Studio-verwalteten Visual Studio-Projektdatei gespeichert. Die Windows Presentation Foundation (WPF)-Projektvorlagen generieren außerdem Dateien, um Unterstützung für strikt typisierte Einstellungen und Ressourcen zur Verfügung stellen. In der folgenden Abbildung werden alle dargestellt:

Projektmappen-Explorer-Bildschirmabbildung

Diese werden von der MSBuild-Projektdatei wie folgt verwaltet:

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  ...
  <ItemGroup>
    <Compile Include="Properties\AssemblyInfo.cs">
      <SubType>Code</SubType>
    </Compile>
    <Compile Include="Properties\Resources.Designer.cs">
      <AutoGen>True</AutoGen>
      <DesignTime>True</DesignTime>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
    <Compile Include="Properties\Settings.Designer.cs">
      <AutoGen>True</AutoGen>
      <DependentUpon>Settings.settings</DependentUpon>
      <DesignTimeSharedInput>True</DesignTimeSharedInput>
    </Compile>
    <EmbeddedResource Include="Properties\Resources.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>Resources.Designer.cs</LastGenOutput>
      <SubType>Designer</SubType>
    </EmbeddedResource>
    <None Include="Properties\Settings.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
      <LastGenOutput>Settings.Designer.cs</LastGenOutput>
    </None>
    <AppDesigner Include="Properties\" />
  </ItemGroup>
  ...
</Project>

Erstellen eines MSBuild-Projekts für WPF

MSBuild-Projekte können entweder über eine Eingabeaufforderung oder über Visual Studio erstellt werden.

Erstellen eines MSBuild-Projekts für WPF über die Eingabeaufforderung

MSBuild-Projekte können durch Aufrufen von msbuild.exe über die Windows-Eingabeaufforderung oder über die Windows Software Development Kit (SDK)-Eingabeaufforderung erstellt werden.

Erstellen eines Projekts

Um ein MSBuild-Projekt zu erstellen, führen Sie msbuild.exe aus und übergeben den Dateinamen des gewünschten MSBuild-Projekts:

msbuild.exe msbuildprojectfile.proj

Erstellen eines sprachspezifischen von Visual Studio generierten Projekts

Sprachspezifische MSBuild-Projektdateien, die von Visual Studio wurden:

  • Wählen Sie eine relevante Dateierweiterung (.csproj, .vbproj) aus.

  • Fügen Sie ein sprachspezifisches Ziel ein (Microsoft.CSharp.targets, Microsoft.VisualBasic.targets).

Im Folgenden wird veranschaulicht, wie Sie ein C#-Projekt über die Eingabeaufforderung erstellen:

msbuild.exe VSGeneratedProjectFileForCSharp.csproj

Im Folgenden wird veranschaulicht, wie Sie ein Visual Basic-Projekt über die Eingabeaufforderung erstellen:

msbuild.exe VSGeneratedProjectFileForVisualBasic.vbproj

Erstellen einer von Visual Studio generierten Projektmappe

msbuild.exe erstellt auch Projektmappendateien (.sln), die von Visual Studio generiert wurden:

msbuild.exe VSGeneratedSolutionFile.sln

Erstellen eines MSBuild-Projekts für WPF in Visual Studio

Wenn Sie Visual Studio verwenden, müssen Sie Ihre Projekte und Projektmappen nicht über die Eingabeaufforderung erstellen. Mit Visual Studio lässt sich beides über IDE ausführen.

Erstellen eines Projekts in Visual Studio

Wenn Sie ein Projekt in Visual Studio erstellen möchten, klicken Sie im Fenster Projektmappen-Explorer mit der rechten Maustaste auf das Projekt und wählen Erstellen.

Erstellen einer Projektmappe in Visual Studio

Zum Erstellen einer Projektmappe führen Sie eine der folgenden Aktionen aus:

  • Drücken Sie F6, um die Projektmappe zu erstellen.

  • Drücken Sie F5, um mit dem Debuggen der Projektmappe zu beginnen.

  • Wählen Sie Erstellen | Projektmappe erstellen aus.

  • Wählen Sie Debuggen | Debuggen starten aus.

  • Wählen Sie Debuggen | Starten ohne Debuggen aus.

Jeder dieser Schritte, der für ein Projekt oder eine Projektmappe ausgeführt wird, veranlasst Visual Studio, msbuild.exe auszuführen, um die entsprechenden MSBuild-Dateien zu erstellen.

Windows Presentation Foundation-Buildpipeline

Beim Erstellen eines WPF-Projekts wird die Kombination aus sprachspezifischen und WPF-spezifischen Zielen aufgerufen. Das Ausführen dieser Ziele wird als Buildpipeline bezeichnet. Die wichtigsten Schritte werden in der folgenden Abbildung dargestellt.

WPF-Buildprozess

Diese Schritte werden in den folgenden Abschnitten ausführlicher erläutert.

Präbuildinitialisierungen

Vor Beginn der Erstellung bestimmt MSBuild den Speicherort wichtiger Tools und Bibliotheken, darunter die folgenden:

  • Der .NET Framework.

  • Die Windows SDK-Verzeichnisse

  • Der Speicherort von WPF-Verweisassemblys

  • Die Eigenschaft für die Assemblysuchpfade

Das Verzeichnis für Verweisassemblys (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\) ist der erste Speicherort, in dem nach Assemblys gesucht wird. In diesem Schritt initialisiert der Buildprozess auch die verschiedenen Eigenschaften und Elementgruppen und führt die erforderlichen Bereinigungen durch.

Auflösen von Verweisen

Der Buildprozess sucht und bindet die Assemblys, die zum Erstellen des Anwendungsprojekts erforderlich sind. Diese Logik ist in der ResolveAssemblyReference-Aufgabe enthalten. Alle in der Projektdatei als Reference deklarierten Assemblys werden der Aufgabe mit Informationen zu Suchpfaden und Metadaten für Assemblys, die bereits im System installiert sind, zur Verfügung gestellt. Die Aufgabe sucht Assemblys und verwendet die Metadaten der installierten Assembly, um die WPF-Kernassemblys herauszufiltern, die in den Ausgabemanifesten nicht angezeigt werden müssen. Auf diese Weise vermeiden Sie redundante Informationen in den ClickOnce-Manifesten. Da die PresentationFramework.dll ein Beispiel für eine Anwendung ist, die auf und für WPF erstellt wurde, insbesondere da sich alle WPF-Assemblys auf jedem Computer, auf dem .NET Framework installiert ist, am selben Speicherort befinden, ist das Einfügen sämtlicher Informationen für alle .NET Framework-Verweisassemblys in den Manifesten nicht erforderlich.

Markupkompilierungsdurchlauf 1

In diesem Schritt werden XAML-Dateien analysiert und kompiliert, sodass während der Laufzeit keine XML analysiert und Eigenschaftenwerte überprüft werden. Die kompilierte XAML-Datei wird zuvor mit Token versehen, sodass das Laden zur Laufzeit sehr viel schneller verläuft als das Laden einer XAML-Datei.

In diesem Schritt werden für jede XAML-Datei, die ein Page-Buildelement ist, die folgenden Aktionen ausgeführt:

  1. Die XAML-Datei wird vom Markupcompiler analysiert.

  2. Eine kompilierte Darstellung wird für diese XAML erstellt und in den Ordner obj\Release kopiert.

  3. Eine CodeDOM-Darstellung einer neuen Teilklasse wird erstellt und in den Ordner obj\Release kopiert.

Außerdem wird eine sprachspezifische Codedatei für jede XAML-Datei generiert. Für eine Page1.xaml-Seite in einem Visual Basic-Projekt wird beispielsweise eine Datei Page1.g.vb generiert und für eine Page1.xaml-Seite in einem C#-Projekt eine Datei Page1.g.cs. Das ".g" im Dateinamen gibt an, dass die Datei generierten Code darstellt, der über eine Deklaration der partiellen Klasse für das Element der oberen Ebene der Markupdatei entspricht (z. B. Page oder Window). Die Klasse wird mit dem partial-Modifizierer in C# (Extends in Visual Basic) deklariert, um anzugeben, dass an einer anderen Stelle noch eine weitere Deklaration für die Klasse vorhanden ist, normalerweise in der Code-Behind-Datei Page1.xaml.cs.

Die partielle Klasse wird von der entsprechenden Basisklasse erweitert (z. B. Page für eine Seite) und implementiert die System.Windows.Markup.IComponentConnector-Schnittstelle. Die IComponentConnector-Schnittstelle verfügt über Methoden zum Initialisieren einer Komponente sowie zum Verbinden von Namen und Ereignissen für Elemente im Inhalt. Folglich sieht die Methodenimplementierung der generierten Codedatei folgendermaßen aus:

public void InitializeComponent() {
    if (_contentLoaded) {
        return;
    }
    _contentLoaded = true;
    System.Uri resourceLocater = 
        new System.Uri(
            "window1.xaml", 
            System.UriKind.RelativeOrAbsolute);
    System.Windows.Application.LoadComponent(this, resourceLocater);
}

Standardmäßig wird Markupkompilierung in derselben AppDomain ausgeführt wie das MSBuild-Modul. Dies ermöglicht einen erheblichen Leistungszuwachs. Dieses Verhalten kann mit der AlwaysCompileMarkupFilesInSeparateDomain-Eigenschaft umgeschaltet werden. Dies hat den Vorteil, dass alle Verweisassemblys durch Entladen der separaten AppDomain entladen werden.

Markupkompilierungsdurchlauf 2

Während des Durchlaufs 1 der Markupkompilierung werden nicht alle XAML-Seiten kompiliert. XAML-Dateien, die lokal definierte Typverweise aufweisen (Verweise auf Typen, die im Code an anderer Stelle im selben Projekt definiert sind), werden derzeit von der Kompilierung ausgenommen. Das liegt daran, dass diese lokal definierten Typen nur im Quellcode existieren und noch nicht kompiliert wurden. Um dies zu bestimmen, verwendet der Parser heuristische Verfahren, die das Suchen nach Elementen umfassen, z. B. x:Name in der Markupdatei. Wird eine solche Instanz gefunden, wird die Kompilierung der Markupdatei bis zur Kompilierung der Codedateien zurückgestellt. Anschließend werden diese Dateien im zweiten Durchlauf der Markupkompilierung verarbeitet.

Dateiklassifizierung

Der Buildprozess fügt Ausgabedateien in verschiedene Ressourcengruppen ein, und zwar abhängig von der Anwendungsassembly, in die sie platziert werden. In einer normalen nicht lokalisierten Anwendung werden alle als Resource markierten Datendateien in der Hauptassembly platziert (ausführbare Datei oder Bibliothek). Wenn UICulture im Projekt festgelegt ist, werden alle kompilierten XAML-Dateien und speziell als sprachspezifisch markierte Ressourcen in die Satellitenressourcenassembly eingefügt. Außerdem werden alle sprachneutralen Ressourcen in die Hauptassembly eingefügt. In diesem Schritt des Buildprozesses wird diese Bestimmung vorgenommen.

Die Buildaktionen ApplicationDefinition, Page und Resource in der Projektdatei können mit den Localizable-Metadaten erweitert werden (zulässige Werte sind true und false), die festlegen, ob die Datei sprachspezifisch oder sprachneutral ist.

Kernkompilierung

In dem Schritt der Kernkompilierung wird die Kompilierung von Codedateien ausgeführt. Dieser Vorgang wird in den sprachspezifischen Zieldateien Microsoft.CSharp.targets und Microsoft.VisualBasic.targets logisch koordiniert. Die Hauptassembly wird generiert, wenn die Heuristik einen einzelnen Durchlauf des Markupcompilers als ausreichend einschätzt. Wenn jedoch eine oder mehrere XAML-Dateien im Projekt Verweise auf lokal definierte Typen aufweisen, wird eine temporäre DLL-Datei generiert, damit die finalen Anwendungsassemblys nach Abschluss des zweiten Durchlaufs der Markupkompilierung erstellt werden können.

Manifestgenerierung

Nachdem alle Anwendungsassemblys und Inhaltsdateien fertiggestellt wurden, werden die ClickOnce-Manifeste am Ende des Buildprozesses für die Anwendung generiert.

Mit der Bereiststellungsmanifestdatei wird das Bereitstellungsmodell beschrieben: die aktuelle Version, Aktualisierungsverhalten und die Identität des Publishers mit der digitalen Signatur. Dieses Manifest sollte von Administratoren erstellt werden, die für die Bereitstellung zuständig sind. Die Dateierweiterung ist .xbap (für XAML-Browseranwendungen (XBAPs)) und .application für installierte Anwendungen. Erstere wird durch die HostInBrowser-Projekteigenschaft vorgeschrieben. Als Ergebnis identifiziert das Manifest die Anwendung als vom Browser gehostet.

Im Anwendungsmanifest (die Datei .exe.manifest) werden die Anwendungsassemblys und abhängigen Bibliotheken beschrieben und die von der Anwendung benötigten Berechtigungen aufgeführt. Diese Datei sollte vom Anwendungsentwickler erstellt werden. Um eine ClickOnce-Anwendung zu starten, öffnet ein Benutzer die Bereitstellungsmanifestdatei der Anwendung.

Diese Manifestdateien werden stets für XBAPs erstellt. Für installierte Anwendungen werden sie nicht erstellt, sofern die GenerateManifests-Eigenschaft in der Projektdatei nicht mit dem Wert true angegeben wird.

XBAPs erhalten zwei zusätzliche Berechtigungen über die Berechtigungen hinaus, die herkömmlichen Anwendungen der Internetzone zugewiesen werden: WebBrowserPermission und MediaPermission. Das WPF-Buildsystem deklariert diese Berechtigungen im Anwendungsmanifest.

Unterstützung für inkrementelle Builds

Das WPF-Buildsystem unterstützt inkrementelle Builds. An Markup oder Code vorgenommene Änderungen werden auf intelligente Weise ermittelt. Außerdem werden nur jene Artefakte kompiliert, die von den Änderungen beeinflusst wurden. Der Mechanismus für inkrementelle Builds verwendet die folgenden Dateien:

  • Die Datei $ (AssemblyName) _MarkupCompiler.Cache zum Verwalten des aktuellen Compilerzustands.

  • Die Datei $ (AssemblyName) _MarkupCompiler.lref, um XAML-Dateien mit Verweisen auf lokal definierte Typen zwischenzuspeichern.

Im Folgenden finden Sie einen Satz von Regeln für inkrementelle Builds:

  • Die Datei ist die kleinste Einheit, bei der das Buildsystem eine Änderung erkennt. Demnach kann das Buildsystem bei einer Codedatei nicht erkennen, ob ein Typ geändert oder ob Code hinzugefügt wurde. Dasselbe gilt für Projektdateien.

  • Der Mechanismus für inkrementelle Builds muss wissen, ob eine XAML-Seite entweder eine Klasse definiert oder andere Klassen verwendet.

  • Wenn sich Reference-Einträge ändern, kompilieren Sie alle Seiten neu.

  • Wenn sich eine Codedatei ändert, kompilieren Sie alle Seiten mit lokal definierten Typverweisen neu.

  • Wenn sich eine XAML-Datei ändert:

    • Wenn XAML als Page im Projekt deklariert wird: Wenn XAML keine lokal definierten Typverweise besitzt, kompilieren Sie diese XAML und alle XAML-Seiten mit lokalen Verweisen neu. Wenn XAML lokale Verweise aufweist, kompilieren Sie alle XAML-Seiten mit lokalen Verweisen neu.

    • Wenn XAML als ApplicationDefinition im Projekt deklariert ist: Kompilieren Sie alle XAML-Seiten neu (Grund: jede XAML verfügt über einen Verweis auf einen eventuell geänderten Application-Typ).

  • Wenn die Projektdatei statt einer XAML-Datei eine Codedatei als Anwendungsdefinition deklariert:

    • Überprüfen Sie, ob sich der ApplicationClassName-Wert in der Projektdatei geändert hat (gibt es einen neuen Anwendungstyp?). Kompilieren Sie in diesem Fall die gesamte Anwendung neu.

    • Kompilieren Sie ansonsten alle XAML-Seiten mit lokalen Verweisen neu.

  • Wenn sich eine Projektdatei ändert: Wenden Sie alle vorangehenden Regeln an, und stellen Sie fest, was neu kompiliert werden muss. Änderungen an den folgenden Eigenschaften lösen eine vollständige Neukompilierung aus: AssemblyName, IntermediateOutputPath, RootNamespace und HostInBrowser.

Folgende Rekompilierungsszenarien sind möglich:

  • Die gesamte Anwendung wird neu kompiliert.

  • Nur XAML-Dateien, die lokal definierte Typverweise enthalten, werden neu kompiliert.

  • Nichts wird neu kompiliert (es hat keine Änderung im Projekt stattgefunden).

Siehe auch

Konzepte

Bereitstellen von WPF-Anwendungen (WPF)

Paket-URIs in Windows Presentation Foundation

Windows Presentation Foundation-Anwendungsressource, Inhalts- und Datendateien

Weitere Ressourcen

Windows Presentation Foundation MSBuild-Referenz

Änderungsprotokoll

Date

Versionsgeschichte

Grund

Juli 2008

Hinzugefügte Informationen über die SplashScreen-Buildeigenschaft.

SP1-Featureänderung.