Génération d'une application WPF (WPF)

Mise à jour : Juillet 2008

Les applications Windows Presentation Foundation (WPF) peuvent être générées comme fichiers exécutables .NET Framework (.exe), comme bibliothèques (.dll) ou une combinaison des deux types d'assemblys. Cette rubrique montre initialement comment générer des applications WPF simples à partir de l'invite de commandes, avant de montrer comment WPF tire parti de l'extensibilité de Microsoft Build Engine (MSBuild) pour générer des applications plus complexes. Cette rubrique se termine en fournissant une discussion détaillée des étapes clés dans le processus de génération MSBuild.

Cette rubrique comprend les sections suivantes.

• Génération d'une application WPF à l'aide de la compilation de ligne de commande
• Génération d'une application WPF à l'aide de MSBuild
• Fichiers projet MSBuild pour WPF
• Création d'un projet MSBuild pour WPF à l'aide de Visual Studio
• Génération d'un projet MSBuild pour WPF
• Pipeline de génération Windows Presentation Foundation
• Support de génération incrémentiel
• Rubriques connexes

Génération d'une application WPF à l'aide de la compilation de ligne de commande

Une application WPF écrite entièrement en code (aucune balise) peut être générée avec un compilateur de ligne de commande. Par exemple, considérez une application autonome C#WPF qui inclut les fichiers de code source suivants :

• Un fichier de définition d'application (app.cs).

• Une fenêtre (mainwindow.cs).

Cette application peut être générée à l'aide du compilateur C#, csc.exe, à partir d'une invite de commandes, comme dans l'exemple suivant :

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"

Dans cet exemple :

• Le paramètre /out spécifie le nom de l'assembly exécutable généré (WPFApplication.exe).

• Le paramètre /target spécifie le type d'assembly compilé (un fichier exécutable Microsoft Windows).

• Les fichiers de code source C# qui composent l'application (app.cs et mainwindow.cs)

• Le paramètre /reference qui identifie les assemblys référencés qui implémentent les types utilisés par l'application.

La compilation de ligne de commande peut être utilisée pour générer des applications plus complexes, bien que le compilateur ne prenne pas en charge les applications WPF qui incluent du code source XAML (Extensible Application Markup Language). En outre, la compilation de ligne de commande ne prend pas en charge la gamme complète de spécifications de génération d'applications WPF typiques, y compris la gestion de la configuration et la génération de manifeste ClickOnce. Prendre en charge ces aspects et d'autres spécifications de génération plus complexes, WPF s'intègre à et étend MSBuild.

Remarque :
Pour plus d'informations sur la compilation de ligne de commande, consultez Génération à partir de la ligne de commande avec csc.exe ou Génération à partir de la ligne de commande (Visual Basic).

Génération d'une application WPF à l'aide de MSBuild

MSBuild est une technologie fiable et extensible, introduite avec le .NET Framework. Le cœur de la technologie MSBuild est implémenté à travers les assemblys décrits dans le tableau suivant.

Assembly	Description
Microsoft.Build.Engine.dll	Lit et traite des fichiers projet MSBuild.
Microsoft.Build.Tasks.dll	Implémente des fonctionnalités qui sont communes à tous les projets MSBuild, y compris l'appel de compilateur de ligne de commande (par exemple, csc.exe pour C#, vbc.exe pour Visual Basic).
Microsoft.Build.Utilities.dll	Expose des classes utilitaires qui étendent MSBuild avec une fonctionnalité de génération personnalisée.
Microsoft.Build.Framework.dll	Implémente des interfaces qui définissent comment les fonctionnalités MSBuild interagissent avec le moteur MSBuild.
Microsoft.Build.Conversion.dll	Prend en charge la conversion de Microsoft Visual Studio .NET 2002 hérité et du format de fichier projet Microsoft Visual Studio .NET 2003 vers le format de fichier projet Microsoft Visual Studio 2005MSBuild.

Remarque :
Pour plus d'informations sur les assemblys MSBuild, consultez Référence MSBuild.

Fichiers projet MSBuild pour WPF

Les assemblys qui composent MSBuild sont connu sous le nom de moteur MSBuild. Pour générer des applications, le moteur MSBuild requiert en général les informations suivantes :

• Références de fichier de code source.

• Références d'assembly dépendant.

• Détails de configuration.

• Spécifications de génération.

Pour être traitées par MSBuild, ces informations sont emballées dans des fichiers XML conformes au schéma MSBuild personnalisé (consultez Référence du schéma de fichier de projet MSBuild). De tels fichiers sont connus sous le nom de fichiers projet MSBuild. Ce qui suit est le fichier projet MSBuild pour une version de l'application WPF que nous avons générée précédemment à l'aide d'un compilateur de ligne de commande, avec l'ajout de fichiers de code source XAML (Extensible Application Markup Language).

<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>

Cet exemple contient les éléments qui sont communs à la plupart des fichiers projet MSBuild, y compris la balise Project, des propriétés, des éléments, des cibles et des tâches.

L'élément de projet

Comme spécifié par le schéma de fichier projet MSBuild, un fichier projet MSBuild est un fichier XML avec Project comme élément de niveau supérieur :

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

L'élément Project est là où le moteur MSBuild démarre un traitement de fichier projet. Pour spécifier la version de MSBuild que les fichiers projet MSBuild ciblent, une déclaration d'espace de noms XML appropriée est fournie.

Propriétés

Les propriétés sont des variables utilisées pour configurer des projets MSBuild et fournir des informations spécifiques à la génération au moteur MSBuild. Les propriétés sont contenues dans des éléments PropertyGroup, comme montré dans l'exemple suivant.

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

Certaines propriétés, telles qu' AssemblyName et OutputType, sont communes à tous les types d'applications et sont décrites dans Propriétés communes des projets MSBuild. Les propriétés MSBuild qui sont spécifiques à WPF sont répertoriées dans le tableau suivant.

Propriété	Description
OutputType	Spécifie le type d'assembly généré et est l'une des valeurs suivantes : winexe : génère un assembly exécutable (.exe). Les applications autonomes et XBAP sont configurées avec ce type de sortie. library : génère un assembly de bibliothèque (.dll). Les assemblys partagés et les bibliothèques de contrôles personnalisés sont configurées avec ce type de sortie.
HostInBrowser	Spécifie si une application WPF est hébergée dans un navigateur, et est l'une des valeurs suivantes : true : Crée une application XBAP, qui inclut l'assembly d'application principal (.exe), un manifeste de déploiement (NomApplication.xbap) et un manifeste d'application (NomApplication.exe.manifest). false : crée une application autonome. Si HostInBrowser est true, le OutputType doit être un winexe.
Install	Spécifie si une application XBAP est installée sur le client. Install peut être true ou false et possède la valeur opposée de HostInBrowser.
GenerateManifests	Spécifie si une application autonome est publiée à l'aide du déploiement ClickOnce, et est l'une des valeurs suivantes : true : crée le fichier exécutable d'application principal, un manifeste de déploiement (NomApplication.application) et un manifeste d'application (NomApplication.exe.manifest). false : crée uniquement le fichier d'application exécutable (.exe). GenerateManifests est utilisé uniquement lorsque Install a une valeur de true.
UICulture	Spécifie les paramètres régionaux pour lesquels l'assembly sera généré. En cas de spécification, les fichiers déclarés comme éléments de projet Resource et les ressources spécifiques à une langue sont compilés dans un assembly satellite pour les paramètres régionaux désirés. Le contenu indépendant du langage, en revanche, est compilé dans l'assembly principal. Par défaut, les applications ne sont pas localisées, et les fichiers de ressources sont par conséquent incorporés dans l'assembly principal. Remarque : Lorsque UICulture est défini, le langage de ressource neutre doit être spécifié à l'aide du NeutralResourcesLanguageAttribute. Cet attribut doit être ajouté au fichier AssemblyInfo d'une application WPF.

Items

Les éléments sont des entrées MSBuild traitées par le moteur MSBuild pendant le processus de génération. Les éléments sont contenus dans un élément ItemGroup.

<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>

Le type d'un élément peut être configuré avec des métadonnées ; dans l'exemple précédent, les références d'assembly sont configurées comme éléments Reference, et les fichiers de code source sont configurés comme éléments Compile. Les éléments Reference et Compile sont communs à toutes les applications .NET Framework et sont décrits plus loin dans Éléments communs des projets MSBuild.

Les éléments MSBuild spécifiques à WPF sont répertoriés dans le tableau suivant.

Propriété	Description
ApplicationDefinition	Identifie le fichier de balisage XAML qui contient la définition d'application (un fichier de balisage XAML dont l'élément racine est Application). ApplicationDefinition est obligatoire lorsque Install est true et OutputType est winexe. Une application WPF et, par conséquent, un projet MSBuild peuvent n'avoir qu'un seul ApplicationDefinition.
Page	Identifie un fichier de balisage XAML dont le contenu est converti en un format binaire et compilé dans un assembly. Les éléments Page sont implémentés en général conjointement à une classe code-behind. Les éléments Page les plus communs sont des fichiers XAML dont les éléments de niveau supérieur sont l'un des suivants : Fenêtre (System.Windows.Window). Page (System.Windows.Controls.Page). PageFunction (System.Windows.Navigation.PageFunction<T>). ResourceDictionary (System.Windows.ResourceDictionary). FlowDocument (System.Windows.Documents.FlowDocument). UserControl (System.Windows.Controls.UserControl).
Resource	Identifie un fichier de ressources compilé dans un assembly d'application. Comme mentionné précédemment, UICulture traite des éléments Resource.
Content	Identifie un fichier de contenu distribué avec une application. Les métadonnées qui décrivent le fichier de contenu sont compilées dans l'application (à l'aide de AssemblyAssociatedContentFileAttribute).
SplashScreen	Identifie un fichier image utilisé pour la fenêtre de démarrage de l'application. L'assembly PresentationBuildTasks génère le code dans App.g.cs ou Application.g.vb qui crée une instance SplashScreen et l'affiche pendant le chargement de l'application. Cet élément est disponible à partir de Visual Studio 2008 SP1.

Cibles

Les cibles déterminent comment les projets sont générés et dépendent des propriétés et des éléments. Une application WPF doit avoir une cible spécifique à une langue et une cible spécifique à WPF.

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

Les cibles sont des fichiers distincts qui se terminent par l'extension .targets. Les fichiers cible inclus avec .NET Framework sont installés dans l'emplacement suivant :

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

La cible spécifique à une langue génère du code source spécifique à une langue. La cible spécifique à une langue pour C# est Microsoft.CSharp.targets et Microsoft.VisualBasic.targets pour  Visual Basic. Ces deux cibles dérivent et prolongent Microsoft.Common.targets, qui exécute le plus gros du travail commun de génération indépendante de la langue. Pour plus d'informations sur les cibles MSBuild communes et spécifiques à une langue, consultez Fichiers .Targets MSBuild.

Le travail de génération spécifique à WPF est exécuté par la cible Microsoft.WinFX.targets. Ce travail inclut la compilation de balise XAML, la génération de manifeste pour applications XBAP et le traitement des ressources WPF et des fichiers de contenu.

Tâches

Une tâche est une classe qui exécute une action de génération spécifique. Une ou plusieurs tâches sont combinées par les cibles pour définir un processus de génération ; lorsque MSBuild traite une cible, il exécute les tâches que contient la cible. Les tâches utilisées par des cibles communes et spécifiques à une langue sont implémentées par l'assembly Microsoft.Build.Tasks, et celles spécifiques à WPF sont implémentées par l'assembly PresentationBuildTasks.

Les cibles assurent la prise en charge pour générer toutes les applications WPF standard. Il est également possible d'utiliser des combinaisons alternatives de tâches pour implémenter le comportement de génération personnalisée. Par exemple, la tâche MSBuildGetWinFXPath suivante est utilisée pour détecter le chemin d'accès natif vers le runtime .NET Framework, qui dépend si la tâche s'exécute ou non sur un processeur 64 bits :

<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>

Pour plus d'informations sur les tâches MSBuild communes, consultez Référence des tâches MSBuild.

Exemples de projets Windows Presentation Foundation MSBuild

Le Kit de développement logiciel (SDK) Windows inclut plusieurs exemples de fichiers de projet MSBuild pour les types les plus communs d'applications WPF :

• Comment : créer un exemple de fichier projet pour une application autonome Windows Presentation Foundation

• Comment : créer un exemple de fichier projet pour une application de navigation autonome Windows Presentation Foundation

• Comment : créer un exemple de fichier projet pour une application de navigateur XAML Windows Presentation Foundation

• Comment : créer un exemple de fichier projet pour une bibliothèque de contrôles personnalisés Windows Presentation Foundation

• Comment : créer un exemple de fichier projet pour une application autonome Windows Presentation Foundation en code seul

Création d'un projet MSBuild pour WPF à l'aide de Visual Studio

Visual Studio génère automatiquement des fichiers projet MSBuild lorsque de nouvelles applications WPF sont créées à l'aide des modèles de projet Visual Studio. Par exemple, le modèle de projet d'application WPF génère le fichier projet suivant (pour 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>

Le nom de l'extension de fichier projet MSBuild générée incorpore le langage de code source :

• Pour les projets C#, l'extension est .csproj.

• Pour les projets Visual Basic, l'extension est . vbproj.

Le fichier projet est plus grand que les exemples précédents, ce qui est dû en partie aux multiples propriétés supplémentaires. Toutefois, les informations supplémentaires sont spécifiques à Visual Studio et incluent les éléments suivants :

• Configuration de projet

• Configuration de génération.

• Association de fichier de code source.

• Propriété de projet par défaut, ressource et gestion des paramètres.

Configuration de projet

Les détails de configuration de projet incluent un identificateur unique pour le projet, un identificateur unique pour le type de projet, et diverses données identifiant la version du .NET Framework et de Visual Studio :

<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>

Configuration de génération

Un projet Visual Studio par défaut a deux configurations de génération : Debug et Release (consultez Configurations de génération). Dans un fichier projet MSBuild, celles-ci sont configurées à l'aide des propriétés :

<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>

La configuration de génération actuelle est spécifiée par la propriété Configuration :

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

Association de fichier de code source

Visual Studio gère une association entre des fichiers de code source connexes, tels que les fichiers de balisage et code-behind. Cela permet à Visual Studio de visualiser l'association dans la fenêtre Explorateur de solutions de Visual Studio :

L'association entre fichiers de code source connexes est effectuée faite à l'aide des métadonnées DependentUpon et SubType :

<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>

Dans ce projet, App.xaml (balise) est associé à App.xaml.cs (code-behind), et Window1.xaml (balise) est associé à Window1.xaml.cs (code-behind).

Propriété de projet par défaut, ressource et gestion des paramètres.

Visual Studio vous permet de modifier visuellement les propriétés d'un projet Visual Studio. La majorité de ceux-ci affectent le processus de génération et sont stockés dans le fichier projet Visual Studio géré par Visual Studio. Les modèles de projet Windows Presentation Foundation (WPF) génèrent également des fichiers pour fournir des paramètres fortement typés et des supports de ressources. Vous les trouverez tous dans l'illustration ci-dessous :

Ceux-ci sont gérés par le fichier projet MSBuild à l'aide des éléments suivants :

<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>

Génération d'un projet MSBuild pour WPF

Des projets MSBuild peuvent être générés à partir d'une invite de commandes ou Visual Studio.

Génération d'un projet MSBuild pour WPF à partir de l'invite de commandes

Des projets MSBuild peuvent être générés en appelant msbuild.exe à partir de l'invite de commande Windows ou de l'invite de commande Kit de développement logiciel (SDK) Windows.

Génération d'un projet

Pour générer un projet MSBuild, vous exécutez msbuild.exe, en passant le nom de fichier du projet MSBuild désiré :

msbuild.exe msbuildprojectfile.proj

Génération d'un projet spécifique à une langue généré par Visual Studio

Les fichiers projet MSBuild spécifiques à une langue générés par Visual Studio :

• Possèdent une extension de fichier pertinente (.csproj, .vbproj).

• Incluent une cible spécifique à une langue (Microsoft.CSharp.targets, Microsoft.VisualBasic.targets).

Les éléments suivants indiquent comment générer un projet C# à partir de l'invite de commandes :

msbuild.exe VSGeneratedProjectFileForCSharp.csproj

Les éléments suivants indiquent comment générer un projet Visual Basic à partir de l'invite de commandes :

msbuild.exe VSGeneratedProjectFileForVisualBasic.vbproj

Génération d'une solution générée par Visual Studio

msbuild.exe générera également des fichiers solution (.sln) générés par Visual Studio :

msbuild.exe VSGeneratedSolutionFile.sln

Génération d'un projet MSBuild pour WPF dans Visual Studio

Si vous utilisez Visual Studio, vous n'avez pas besoin de générer vos projets et solutions à partir de l'invite de commandes ; Visual Studio vous permet de faire les deux à partir de l'IDE.

Génération d'un projet dans Visual Studio

Pour générer un projet dans Visual Studio, cliquez avec le bouton droit sur le projet dans la fenêtre Explorateur de solutions et choisissez Générer.

Génération d'une solution dans Visual Studio

Pour générer une solution, vous pouvez effectuer l'une des actions suivantes :

• Appuyez sur F6 pour générer la solution.

• Appuyez sur F5 pour démarrer le débogage de la solution.

• Choisissez Générer | Générer la solution.

• Choisissez Débogage | Démarrer le débogage.

• Choisissez Débogage | Exécuter sans débogage.

L'un ou l'autre de ces choix pour un projet ou une solution entraîne l'exécution de msbuild.exe par Visual Studio pour générer les fichiers MSBuild appropriés.

Pipeline de génération Windows Presentation Foundation

Lorsqu'un projet WPF est généré, la combinaison de cibles spécifiques à une langue et spécifiques à WPF est appelée. Le processus d'exécution de ces cibles est appelé le pipeline de génération, et les étapes clés sont représentées par l'illustration suivante.

Ces étapes sont décrites plus en détail dans les sections suivantes.

Initialisations avant génération

Avant la génération, MSBuild détermine l'emplacement des outils et des bibliothèques importants, y compris les éléments suivants :

• .NET Framework.

• Les répertoires Kit de développement logiciel (SDK) Windows.

• L'emplacement d'assemblys de référence WPF.

• La propriété pour les chemins de recherche des assemblys.

Le répertoire de l'assembly de référence (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\) est le premier emplacement où les assemblys sont recherchés. Pendant cette étape, le processus de génération initialise également les diverses propriétés et groupes d'éléments et exécute tout travail de nettoyage requis.

Résolution de références

Le processus de génération localise et lie les assemblys requis pour générer le projet d'application. Cette logique est contenue dans la tâche ResolveAssemblyReference. Tous les assemblys déclarés comme Reference dans le fichier projet sont fournis à la tâche avec les informations sur les chemins de recherche et les métadonnées sur les assemblys déjà installés sur le système. La tâche examine les assemblys et utilise les métadonnées de l'assembly installé pour éliminer par filtrage les assemblys WPF principaux qui ne doivent pas apparaître dans les manifestes de sortie. Cela est fait pour éviter des informations redondantes dans les manifestes ClickOnce. Par exemple, comme PresentationFramework.dll peut être considéré être représentatif d'une application générée sur et pour le WPF et, qui plus est, comme tous les assemblys WPF existent au même emplacement sur chaque ordinateur où .NET Framework est installé, il n'est pas besoin d'inclure toutes les informations sur tous les assemblys .NET Framework de référence dans les manifestes.

Compilation de la balise—Passe 1

Dans cette étape, les fichiers XAML sont analysés et compilés afin que le runtime ne perde pas de temps à analyser XML et à valider des valeurs de propriété. Le fichier XAML compilé est sous forme de pré-jetons de sorte que, lors de l'exécution, le chargement devrait être beaucoup plus rapide que le chargement d'un fichier XAML.

Pendant cette étape, les activités suivantes ont lieu pour chaque fichier XAML qui est un élément de génération Page :

1. Le fichier XAML est analysé par le compilateur de balise.

2. Une représentation compilée est créée pour ce XAML et copiée dans le dossier obj\Release.

3. Une représentation CodeDOM d'une nouvelle classe partielle est créée et copiée dans le dossier obj\Release.

Un fichier de code spécifique à une langue est par ailleurs généré pour chaque fichier XAML. Par exemple, pour une page Page1.xaml dans un projet Visual Basic, un Page1.g.vb est généré ; pour une page Page1.xaml dans un projet C#, un Page1.g.cs est généré. Le ".g" dans le nom de fichier indique que le fichier est du code généré qui a une déclaration de classe partielle pour l'élément de niveau supérieur du fichier de balisage (tel que Page ou Window). La classe est déclarée avec le modificateur partial dans C# (Extends dans Visual Basic) pour indiquer qu'une autre déclaration existe ailleurs pour la classe, habituellement dans le fichier code-behind Page1.xaml.cs.

La classe partielle s'étend de la classe de base appropriée (telle que Page pour une page) et implémente l'interface System.Windows.Markup.IComponentConnector. L'interface IComponentConnector a des méthodes pour initialiser un composant et connecter des noms et des événements sur les éléments dans son contenu. Par conséquent, le fichier de code généré a une implémentation de méthode comme suit :

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);
}

Par défaut, la compilation de balise s'exécute dans le même AppDomain que le moteur MSBuild. Cela assure des gains de performance significatifs. Ce comportement peut être basculé avec la propriété AlwaysCompileMarkupFilesInSeparateDomain. Cela présente l'avantage de décharger tous les assemblys de référence en déchargeant le AppDomain séparé.

Compilation de la balise—Passe 2

Toutes les pages XAML ne sont pas compilées pendant la passe 1 de compilation de balise. Les fichiers XAML qui comportent des références de type définies localement (références aux types définis ailleurs dans du code dans le même projet) sont exemptés de compilation à ce stade. Ceci parce que les types localement définis existent uniquement dans la source et n'ont pas encore été compilés. Pour déterminer ceci, l'analyseur utilise des heuristiques qui impliquent la recherche d'éléments tels que x:Name dans le fichier de balisage. Lorsqu'une telle instance est trouvée, la compilation de ce fichier de balisage est remise à plus tard jusqu'à ce que les fichiers de code aient été compilés, après quoi la deuxième passe de la compilation de la balise traite ces fichiers.

Classification des fichiers

Le processus de génération place les fichiers de sortie dans des groupes de ressource différents en fonction de l'assembly d'application dans lequel ils seront placés. Dans une application typique non localisée, tous les fichiers de données marqués comme Resource sont placés dans l'assembly principal (fichier exécutable ou bibliothèque). Lorsque UICulture est défini dans le projet, tous les fichiers XAML compilés et les ressources marquées spécifiquement comme spécifiques à une langue sont placés dans l'assembly de ressource satellite. En outre, toutes les ressources indépendantes du langage sont placées dans l'assembly principal. Cette détermination est faite lors de cette étape du processus de génération.

Les ApplicationDefinition, Page et les actions de génération Resource dans le fichier projet peuvent être augmentés avec les métadonnées Localizable (les valeurs acceptables sont true et false), qui déterminent si le fichier est spécifique ou indépendant du langage.

Compilation principale

L'étape de compilation principale implique la compilation de fichiers de code. Cela répond à une logique dans les fichiers cibles Microsoft.CSharp.targets et Microsoft.VisualBasic.targets spécifiques à une langue. Si les heuristiques ont déterminé qu'un seul passage du compilateur de balisage suffit, l'assembly principal est alors généré. Toutefois, si un ou plusieurs fichiers XAML dans le projet ont des références à des types définis localement, un fichier .dll temporaire est alors généré afin que les derniers assemblys d'application puissent être créés après la fin de la deuxième passe de compilation de balise.

Génération de manifeste

À la fin du processus de génération, après que tous les assemblys d'application et les fichiers de contenu sont prêts, les manifestes ClickOnce pour l'application sont générés.

Le fichier manifeste de déploiement décrit le modèle de déploiement : la version actuelle, le comportement de mise à jour et l'identité d'éditeur avec la signature numérique. Ce manifeste est prévu pour être créé par les administrateurs qui gèrent le déploiement. L'extension de fichier est .xbap (pour les applications du navigateur XAML (XBAP)) et .application pour les applications installées. La première extension est déterminée par la propriété du projet HostInBrowser et, en conséquence, le manifeste identifie l'application comme étant hébergée par le navigateur.

Le manifeste de l'application (un fichier .exe.manifest) décrit les assemblys d'application et les bibliothèques dépendantes et répertorie les autorisations requises par l'application. Ce fichier est prévu pour être créé par le développeur d'applications. Pour lancer une application ClickOnce, un utilisateur ouvre le fichier manifeste de déploiement de l'application.

Ces fichiers manifeste sont toujours créés pour XBAP. Pour les applications installées, ils ne sont pas créés à moins que la propriété GenerateManifests ne soit spécifiée dans le fichier projet avec la valeur true.

Les applications XBAP obtiennent deux autorisations supplémentaires en plus de celles assignées aux applications de zone Internet typiques : WebBrowserPermission et MediaPermission. Le système de génération WPF déclare ces autorisations dans le manifeste de l'application.

Support de génération incrémentiel

Le système de génération WPF fournit le support pour les générations incrémentielles. Il est assez intelligent pour détecter les modifications apportées à la balise ou au code, et il compile uniquement les artefacts affectés par la modification. Le mécanisme de génération incrémentiel utilise les fichiers suivants :

• Un fichier $ (NomAssembly)_MarkupCompiler.Cache pour gérer l'état du compilateur actuel.

• Un fichier $ (NomAssembly)_MarkupCompiler.lref pour mettre en cache les fichiers XAML avec les références aux types définis localement.

Les éléments suivants sont un jeu des règles gouvernant la génération incrémentielle :

• Le fichier est la plus petite unité au niveau de laquelle le système de génération détecte une modification. Ainsi, pour un fichier de code, le système de génération ne peut pas déterminer si un type a été modifié ou si du code a été ajouté. Le même raisonnement s'applique aux fichiers projet.

• Le mécanisme de génération incrémentiel doit être informé qu'une page XAML définit une classe ou utilise d'autres classes.

• Si des entrées Reference sont modifiées, vous devez recompiler toutes les pages.

• Si un fichier de code est modifié, recompiler toutes les pages avec des références définies localement.

• Si un fichier XAML est modifié :

  • Si XAML est déclaré comme Page dans le projet : si le XAML ne contient pas de références de type définies localement, recompiler ce XAML plus toutes les pages XAML avec des références locales ; si le XAML contient des références locales, recompiler toutes les pages XAML avec les références locales.

  • Si XAML est déclaré comme ApplicationDefinition dans le projet : recompiler toutes les pages XAML (raison : chaque XAML fait référence à un type Application qui a pu changer).

• Si le fichier projet déclare un fichier de code comme définition d'application au lieu d'un fichier XAML :

  • Vérifiez si la valeur ApplicationClassName dans le fichier projet a changé (y a-t-il un nouveau type d'application ?). Si c'est le cas, recompiler toute l'application.

  • Sinon, recompiler toutes les pages XAML avec des références locales.

• Si un fichier projet change : appliquer toutes les règles précédentes et voir ce qui doit être recompilé. Les modifications apportées aux propriétés suivantes entraînent une recompilation complète : AssemblyName, IntermediateOutputPath, RootNamespace et HostInBrowser.

Les scénarios de recompilation suivants sont possibles :

• Toute l'application est recompilée.

• Seuls les fichiers XAML qui contiennent des références de type définies localement sont recompilés.

• Rien n'est recompilé (si rien dans le projet n'a changé).

Voir aussi

Concepts

Déploiement d'une application WPF (WPF)

URI à en-tête pack dans Windows Presentation Foundation

Fichiers de ressources, de contenu et de données d'une application Windows Presentation Foundation

Autres ressources

Référence MSBuild - Windows Presentation Foundation

Historique des modifications

Date	Historique	Raison
Juillet 2008	Ajout d'informations sur la propriété de génération SplashScreen.	Modifications de fonctionnalités dans le SP1.