Построение приложения WPF

Обновлен: Июль 2008

Приложения WPF (Windows Presentation Foundation) могут быть построены как исполняемые файлы (.exe), библиотеки (.dll) или как комбинация обоих типов сборки .NET Framework. Сначала в этом разделе показано, как строить простые приложения WPF из командной строки, затем как WPF использует расширение среды MSBuild (Microsoft build engine) для построения более сложных приложений. И наконец, подробно описываются ключевые шаги процесса построения MSBuild.

В этом разделе содержатся следующие подразделы.

• Построение приложения WPF с помощью компиляции из командной строки
• Построение приложения WPF с помощью MSBuild
• Файлы проекта MSBuild для WPF
• Создание проекта MSBuild для WPF с помощью Visual Studio
• Построение проекта MSBuild для WPF
• Конвейер построения Windows Presentation Foundation
• Поддержка инкрементного построения
• Связанные разделы

Построение приложения WPF с помощью компиляции из командной строки

Приложение WPF, целиком написанное в коде (без макета), может быть построено с помощью компилятора командной строки. Например, рассмотрим изолированное приложение C# на WPF, которое содержит следующие файлы исходного кода:

• Файл определения приложения (app.cs).

• Окно (mainwindow.cs).

Это приложение может быть построено с помощью компилятора C#, csc.exe, из командной строки, как показано в следующем примере:

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"

В этом примере:

• Параметр /out задает имя построенной исполняемой сборки (WPFApplication.exe).

• Параметр /target задает тип компилируемой сборки (исполняемый файл Microsoft Windows).

• Файлы исходного кодаC#, создающие приложение (app.cs и mainwindow.cs)

• Параметр /reference идентифицирует указанные сборки, которые реализуют типы, используемые приложением.

Компиляцию из командной строки можно использовать для построения более сложных приложений, хотя компилятор не поддерживает приложения WPF, содержащие исходный код Язык XAML (Extensible Application Markup Language). Кроме того, компиляция из командной строки не поддерживает весь диапазон требований построения обычных приложений WPF, включая управление конфигурацией и создание манифеста ClickOnce. Для поддержки этих и других более сложных требований построения WPF интегрируется вместе с MSBuild и расширяет его.

Примечание.
Дополнительные сведения о компиляции из командной строки см. в разделе Построение из командной строки с помощью csc.exe или Построение из командной строки (Visual Basic).

Построение приложения WPF с помощью MSBuild

MSBuild — это надежная расширяемая технология, которая была введена вместе с .NET Framework. Ядро технологии MSBuild реализуется в сборках, которые описаны в следующей таблице.

Сборка	Описание
Microsoft.Build.Engine.dll	Считывает и обрабатывает файлы проекта MSBuild.
Microsoft.Build.Tasks.dll	Реализует функциональность, общую для всех проектов MSBuild, включая вызов компилятора командной строки (например, csc.exe для C#, vbc.exe для Visual Basic).
Microsoft.Build.Utilities.dll	Предоставляет служебные классы, расширяющие MSBuild настраиваемыми функциональными возможностями построения.
Microsoft.Build.Framework.dll	Реализует интерфейсы, которые определяют взаимодействие функциональных возможностей MSBuild с ядром MSBuild.
Microsoft.Build.Conversion.dll	Поддерживает преобразование из формата файлов проекта старых версий Microsoft Visual Studio .NET 2002 и Microsoft Visual Studio .NET 2003 в формат файлов проекта MSBuild версии Microsoft Visual Studio 2005.

Примечание.
Дополнительные сведения о сборках MSBuild см. в разделе Справочные сведения о MSBuild.

Файлы проекта MSBuild для WPF

Сборки, составляющие MSBuild, называют ядром MSBuild. Для построения приложений ядру MSBuild обычно требуются следующие сведения:

• Ссылки на файлы исходного кода.

• Ссылки на зависимые сборки.

• Детали конфигурации.

• Требования построения.

Для обработки ядром MSBuild эта информация упаковывается в файлы XML, соответствующие пользовательской схеме MSBuild (см. Справочные сведения о схеме файлов проектов MSBuild). Такие файлы называются файлами проекта MSBuild. Ниже приведен файл проекта MSBuild для версии созданного ранее с помощью компилятора командной строки приложения WPF и файлы исходного кода Язык 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>

В этом примере содержатся элементы, общие для большинства файлов проекта MSBuild, включая тег Project, properties (свойства), items (элементы), targets (цели) и tasks (задачи).

Элемент Project

Заданный схемой файлов проекта MSBuild файл проекта MSBuild ۗ— это файл XML с Project в качестве элемента верхнего уровня:

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

Ядро MSBuild начинает обработку файла проекта именно с элемента Project. Чтобы задать версию MSBuild, на которую ориентирован файл проекта MSBuild, предоставляется соответствующее объявление пространства имен XML.

Свойства

Свойства — это переменные, которые используются для настройки проектов MSBuild и для предоставления ядру MSBuild особых сведений построения. Свойства содержатся в элементах PropertyGroup, как показано в следующем примере.

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

Некоторые свойства, например, AssemblyName и OutputType, являются общими для всех типов приложений и описаны в разделе Общие свойства проектов MSBuild. Свойства MSBuild, относящиеся к WPF, перечислены в следующей таблице.

Свойство	Описание
OutputType	Задает тип создаваемой сборки, принимает одно из следующих значений: winexe: создает исполняемую сборку (.exe). Этот тип выходных данных имеют изолированные приложения и XBAP. library: создает библиотечную сборку (.dll). Этот тип выходных данных имеют совместно используемые сборки и библиотеки пользовательских элементов управления.
HostInBrowser	Определяет, размещено ли приложение WPF в обозревателе; принимает одно из следующих значений: true: создает XBAP, который включает в себя сборку главного приложения (.exe), манифест развертывания (имя_приложения.xbap) и манифест приложения (имя_приложения.exe.manifest). false: создает изолированное приложение. Если параметр HostInBrowser принимает значение true, то OutputType должен быть winexe.
Install	Определяет, установлен ли XBAP на клиенте. Install может принимать значения true или false и имеет значение, противоположное HostInBrowser.
GenerateManifests	Определяет, опубликовано ли изолированное приложение с помощью развертывания ClickOnce; принимает одно из следующих значений: true: создает исполняемый файл основного приложения, манифест развертывания (имя_приложения.application) и манифест приложения (имя_приложения.exe.manifest). false: создает только исполняемый файл приложения (.exe). GenerateManifests используется только, когда Install имеет значение true.
UICulture	Определяет языковой стандарт, для которого будет построена сборка. Когда свойство задано, файлы, объявленные как элементы проекта Resource, и ресурсы, определенные для конкретного языка, компилируются в сопутствующую вспомогательную сборку для нужного языкового стандарта. А нечувствительное к языку содержимое компилируется в основную сборку. По умолчанию приложения не локализуются, а файлы ресурсов последовательно встраиваются в основную сборку. Примечание. Когда UICulture задано, язык нейтральных ресурсов должен быть задан с помощью NeutralResourcesLanguageAttribute. Этот атрибут должен быть добавлен в файл AssemblyInfo приложения WPF.

Элементы

Элементы — это входные данные MSBuild, которые обрабатываются ядром MSBuild во время процесса построения. Элементы содержатся внутри элемента 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>

Тип элемента может настраиваться с помощью метаданных; в предыдущем примере ссылки на сборки настраиваются как элементы Reference, а файлы исходного кода настраиваются как элементы Compile. Reference и Compile являются общими для всех приложений .NET Framework и описаны в разделе Общие элементы проектов MSBuild.

Зависящие от WPF элементы MSBuild перечислены в следующей таблице.

Свойство	Описание
ApplicationDefinition	Определяет файл разметки XAML, содержащий определение приложения (файл разметки XAML, корневым элементом которого является Application). ApplicationDefinition является обязательным, если Install имеет значение true, а OutputType имеет значение winexe. Приложение WPF и, следовательно, проект MSBuild может иметь только одно определение приложения ApplicationDefinition.
Page	Определяет файл разметки XAML, содержимое которого преобразуется в двоичный формат и компилируется в сборку. Элементы Page обычно реализуются в сочетании с классом с выделенным кодом. Наиболее распространенные элементами Page являются файлы XAML, элементы верхнего уровня которых являются одним из следующих: Окно (System.Windows.Window). Страница (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	Определяет файл ресурсов, который компилируется в сборку приложения. Как упоминалось ранее, UICulture обрабатывает элементы Resource.
Content	Определяет файл содержимого, который распространяется вместе с приложением. Метаданные, описывающие файл содержимого, компилируются в приложение (с помощью AssemblyAssociatedContentFileAttribute).
SplashScreen	Идентифицирует файл изображения, используемый для окна запуска приложения. Сборка PresentationBuildTasks создает код в файле App.g.cs или Application.g.vb, в котором создается экземпляр класса окна запуска SplashScreen, которое отображается при загрузке приложения. Этот элемент доступен, начиная с версии Visual Studio 2008 с пакетом обновления 1 (SP1).

Целевые объекты

Файлы целей определяют, как проекты строятся и как они зависят от свойств и элементов. Приложение WPF должно обладать файлом целей, специфичным для языка, и файлом целей, специфичным для WPF.

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

Файлы целей — это файлы с расширением TARGETS. Файлы целей, входящие в состав .NET Framework, устанавливаются в следующую папку:

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

Файл целей, специфичный для языка, создает исходный код, зависящий от конкретного языка. Зависящим от языка файлом целей для C# является Microsoft.CSharp.targets, для  Visual Basic — Microsoft.VisualBasic.targets. Оба этих файла целей являются производными от файла целей Microsoft.Common.targets и расширяют его; Microsoft.Common.targets выполняет значительную часть работы по общему, не зависящему от языка построению. Дополнительные сведения об общих и зависящих от языка файлов целей MSBuild см. в разделе Файлы Targets в MSBuild.

Специфичная для WPF работа по построению выполняется файлом целей Microsoft.WinFX.targets. Эта работа включает компиляцию разметки XAML, генерацию манифеста приложений XBAP, обработку файлов ресурсов и содержимого WPF.

Задачи

Задача — это класс, выполняющий специфичные действия по построению. Одна или несколько задач объединяются файлами целей для определения процесса построения; когда MSBuild обрабатывает файл целей, он выполняет задачи, содержащиеся в файле целей. Задачи, которые используются общими и зависящими от языка файлами целей, реализовываются сборкой Microsoft.Build.tasks, а задачи, специфичные для WPF, реализуются сборкой PresentationBuildTasks.

Файлы целей предоставляют поддержку для построения всех стандартных приложений WPF. Также возможно использование для реализации настраиваемого поведения построения альтернативных комбинаций задач. Например, следующая задача GetWinFXPath MSBuild используется для обнаружения внутреннего пути к среде выполнения .NET Framework, который зависит от того, выполняется ли задача на 64-разрядном процессоре:

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

Дополнительные сведения об общих задачах MSBuild см. в разделе Справочные сведения о задачах MSBuild.

Примеры проектов MSBuild в Windows Project Foundation

Пакет средств разработки программного обеспечения (SDK) для Windows включает несколько примеров файлов проекта MSBuild для большинства общих типов приложений WPF:

• Практическое руководство. Создание примера файла проекта автономного приложения Windows Presentation Foundation

• Практическое руководство. Создание образца файла проекта автономного приложения навигации Windows Presentation Foundation

• Практическое руководство. Создание примера файла проекта приложения обозревателя XAML Windows Presentation Foundation

• Практическое руководство. Создание шаблона файла проекта для библиотеки пользовательских элементов управления Windows Presentation Foundation

• Практическое руководство. Создание примера файла проекта автономного приложения Windows Presentation Foundation, созданного только в коде

Создание проекта MSBuild для WPF с помощью Visual Studio

Visual Studio автоматически создает файлы проекта MSBuild при создании нового приложения WPF с помощью шаблонов проекта Visual Studio. Например, шаблон проекта приложения WPF создает следующий файл проекта (для 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>

Расширение созданного файла проекта MSBuild включает язык исходного кода:

• Для проектов C# используется расширение CSPROJ.

• Для проектов Visual Basic используется расширение VBPROJ.

Файл проекта больше, чем в предыдущих примерах, частично из-за нескольких дополнительных свойств. Однако дополнительные сведения — это специфические сведения Visual Studio, включающие следующее:

• конфигурацию проекта;

• конфигурацию построения;

• привязку файлов исходного кода;

• свойства, управление настройками и ресурсы проекта по умолчанию.

Конфигурация проекта

Сведения о конфигурации проекта включают уникальный идентификатор проекта, уникальный идентификатор типа проекта и различные данные, определяющие версии платформы .NET Framework и 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>

Конфигурация построения

Проект Visual Studio по умолчанию имеет две конфигурации построения: Debug и Release (см. раздел Конфигурации построений). В файле проекта MSBuild они настроены с помощью свойств:

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

Текущая конфигурация построения задается свойством Configuration:

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

Привязка файлов исходного кода

Visual Studio поддерживает связь между связанными файлами исходного кода, такими как файлы разметки и файлы фонового кода. Это позволяет Visual Studio визуализировать связи в окне обозревателя решений Visual Studio:

Связь между связанными файлами исходного кода осуществляется с помощью метаданных DependentUpon и 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>

В этом проекте файл App.xaml (разметки) связан с файлом App.xaml.cs (фонового кода), файл Window1.xaml (разметки) связан с файлом Window1.xaml.cs (фонового кода).

Свойства, управление настройками и ресурсы проекта по умолчанию

Visual Studio позволяет редактировать свойства проекта Visual Studio в визуальном режиме. Большая их часть влияет на процесс построения и хранится в управляемом Visual Studio файле проекта Visual Studio. Шаблоны проекта WPF (Windows Presentation Foundation) также создают файлы для обеспечения строго типизированных параметров и поддержки ресурсов. Все это показано на следующем рисунке:

Свойства, ресурсы и параметры проекта управляются файлом проекта MSBuild следующим образом:

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

Построение проекта MSBuild для WPF

Проекты MSBuild могут быть построены из командной строки или в Visual Studio.

Построение проекта MSBuild для WPF из командной строки

Проекты MSBuild могут быть построены путем вызова msbuild.exe из командной строки Windows или из командной строки Пакет средств разработки программного обеспечения (пакет SDK) для Windows.

Сборка проекта

Чтобы построить проект MSBuild, выполните msbuild.exe, передав имя файла нужного проекта MSBuild:

msbuild.exe msbuildprojectfile.proj

Построение зависимого от языка проекта, созданного в Visual Studio

Зависимые от языка файлы проекта MSBuild, создаваемые Visual Studio:

• Имеют соответствующее расширение файла (CSPROJ, VBPROJ).

• Включают цель, специфическую для языка (Microsoft.CSharp.targets, Microsoft.VisualBasic.targets).

Ниже показано, как построить проект C# из командной строки:

msbuild.exe VSGeneratedProjectFileForCSharp.csproj

Ниже показано, как построить проект Visual Basic из командной строки:

msbuild.exe VSGeneratedProjectFileForVisualBasic.vbproj

Построение решения, созданного Visual Studio

msbuild.exe также построит файлы решения (.sln), которые были созданы Visual Studio:

msbuild.exe VSGeneratedSolutionFile.sln

Построение проекта MSBuild для WPF в Visual Studio

При использовании Visual Studio нет необходимости строить проекты и решения из командной строки; Visual Studio позволяет сделать это в Интегрированная среда разработки.

Построение проекта в Visual Studio

Чтобы построить проект в Visual Studio, щелкните правой кнопкой мыши проект в окне обозревателя решений и выберите Построить.

Построение решения в Visual Studio

Чтобы построить решение, необходимо выполнить одно из следующих действий.

• Нажать клавишу F6 для построения решения.

• Нажать клавишу F5 для запуска отладки решения.

• Выбрать Построение | Построить решение.

• Выбрать Отладка | Начать отладку.

• Выбрать Отладка | Запуск без отладки.

После выполнения любого из этих действий для проекта или решения Visual Studio запустит msbuild.exe для построения соответствующих файлов MSBuild.

Конвейер построения Windows Presentation Foundation

Когда проект WPF собран, вызывается комбинация файлов целей, зависимых от конкретного языка и от WPF. Процесс выполнения этих файлов целей называется конвейер построения, его ключевые шаги показаны в следующей схеме.

Эти действия описаны более подробно в следующих разделах.

Инициализации перед построением

Перед построением MSBuild определяет расположение важных средств и библиотек, в том числе следующих:

• .NET Framework.

• Каталоги Пакет SDK для Windows.

• Расположение сборок ссылок WPF.

• Свойство для путей поиска сборки.

Папка сборок ссылок (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\) является первым каталогом, где выполняется поиск сборок. На этом шаге процесс построения также инициализирует различные свойства и группы элементов, а также выполняет все необходимые работы по очистке.

Разрешение ссылок

Процесс построения находит и привязывает сборки, которые требуются для построения проекта приложения. Логика процесса содержится в задаче ResolveAssemblyReference. Все сборки, объявленные в файле проекта как Reference, предоставляются задаче вместе с информацией о путях поиска и метаданными о сборках, уже установленных в системе. Задача ищет сборки и использует метаданные установленной сборки для фильтрации этих основных сборок WPF, которые не должны отображаться в манифесте выходных данных. Это делается, чтобы избежать избыточных данных в манифесте ClickOnce. Например, так как PresentationFramework.dll может считаться представителем приложения, построенного на и для WPF и, кроме того, поскольку все сборки WPF расположены в одном и том же месте на каждом компьютере, на котором установлен .NET Framework, нет необходимости включать в манифесты все сведения о всех сборках ссылок .NET Framework.

Компиляция разметки — этап 1

На этом шаге файлы XAML синтаксически разбираются и компилируются, чтобы среда выполнения далее не тратила время на разбор XML и проверку значений свойств. Скомпилированный файл XAML заранее размечен, так что во время выполнения его загрузка занимает намного меньше времени, чем загрузка файла XAML.

На этом шаге для каждого файла XAML, являющегося элементом, построенным Page, выполняются следующие действия:

1. Файл XAML разбирается компилятором разметки.

2. Для этого XAML создается скомпилированное представление, затем оно копируется в папку obj\Release.

3. Создается представление CodeDOM нового частичного класса, затем оно копируется в папку obj\Release.

Кроме того, для каждого файла XAML создается специфический для языка файл кода. Например, для страницы Page1.xaml в проекте Visual Basic создается Page1.g.vb; для страницы Page1.xaml в проекте C# создается Page1.g.cs. ".g" в имени файла показывает, что файл является созданным кодом с объявлением частичного класса для верхнеуровневого элемента файла разметки (например, Page или Window). Класс объявлен в C# с модификатором partial (в Visual Basic с модификатором Extends), означающим, что где-то в другом месте есть другое объявление класса, обычно в файле с выделенным кодом Page1.xaml.cs.

Частичный класс расширяется от соответствующего базового класса (например, Page для страницы) и реализует интерфейс System.Windows.Markup.IComponentConnector. В интерфейсе IComponentConnector есть методы инициализации компонента и связывания имен и событий элемента в его содержимом. Следовательно, в созданном файле кода есть реализация метода, как, например, показано далее:

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

По умолчанию компиляция разметки выполняется в том же AppDomain, что и ядро MSBuild. Это обеспечивает значительное преимущество в производительности. Такое поведение может быть переключено с помощью свойства AlwaysCompileMarkupFilesInSeparateDomain. Так можно получить преимущество при выгрузке все сборок ссылок при выгрузке отдельного AppDomain.

Компиляция разметки — этап 2

Не все страницы XAML компилируются на этапе 1 компиляции разметки. Файлы XAML, для которых ссылки на типы (ссылки на типы, определенные в коде в другом месте того же проекта) локально определены, исключаются из компиляции на этом этапе. Это происходит потому, что эти локально определенные типы существуют только в исходном коде и еще не скомпилированы. Чтобы определить это, синтаксический анализатор использует эвристику, вызывающую поиск элементов, таких как x:Name, в файле разметки. Если такой экземпляр обнаруживается, компиляция этого файла разметки откладывается до тех пор, пока файлы кода не будут скомпилированы, после чего второй этап компиляции разметки будет обрабатывать эти файлы.

Классификация файлов

Процесс построения помещает выходные файлы в различных группы ресурсов, основываясь на том, в какую сборку приложения они будут помещены. В обычном нелокализованном приложении все файлы, отмеченные как Resource, помещаются в главную сборку (исполняемый файл или библиотеку). Когда в проекте задан UICulture, все скомпилированные файлы XAML и ресурсы, специально отмеченные как специфичные для конкретного языка, помещаются в сопутствующую сборку ресурсов. Кроме того, все нейтральные для языка ресурсы помещаются в основную сборку. На этом шаге процесса построения производится определение.

Действия построения ApplicationDefinition, Page и Resource в файле проекта могут быть дополнены метаданными Localizable (допустимые значения — true и false), которые указывают, является ли файл зависящим или не зависящим от языка.

Основная компиляция

На этапе основной компиляции осуществляется компиляция файлов кода. Это происходит по логике, содержащейся в специфичных для языка файлах целей Microsoft.CSharp.targets и Microsoft.VisualBasic.targets.. Если эвристика определила, что первого этапа компилятора разметки достаточно, то создается основная сборка. Тем не менее, если один или несколько файлов XAML в проекте имеют ссылки на локально определенные типы, то затем создается временный DLL-файл, чтобы по завершении второго этапа компиляции разметки могли быть созданы окончательные сборки приложения.

Создание манифеста

В конце процесса построения, при готовности всех сборок приложения и файлов содержимого, для приложения создаются манифесты ClickOnce.

Файл манифеста развертывания описывает модель развертывания: текущую версию, поведение обновления и идентификатор издателя вместе с цифровой подписью. Этот манифест должен быть написан администраторами, управляющими развертыванием. Расширение файла: XBAP (для XBAP (XAML browser applications — приложения обозревателя XAML)) и APPLICATION для установленных приложений. Первое расширение определяется свойством HostInBrowser проекта, и в результате манифест идентифицирует приложение как приложение, размещенное в обозревателе.

Манифест приложения (файл .exe.manifest) описывает сборки приложения и зависимые библиотеки и перечисляет разрешения, необходимые для приложения. Этот файл должен быть написан разработчиком приложения. Чтобы запустить приложение ClickOnce, пользователь открывает файл манифеста развертывания приложения.

Эти файлы манифеста всегда создаются для XBAP. Для установленных приложений они не создаются, если в файле проекта свойство GenerateManifests не имеет значение true.

XBAP получают два дополнительных и более высокоприоритетных разрешения, чем присвоенные обычным приложениям зоны "Интернет": WebBrowserPermission и MediaPermission. Система построения WPF объявляет эти разрешения в манифесте приложения.

Поддержка инкрементного построения

Система построения WPF обеспечивает поддержку инкрементного построения. Она довольно умело обнаруживает изменения в разметке и коде, и она компилирует только те фрагменты, на которые влияют изменения. Механизм инкрементного построения использует следующие файлы:

• Файл $(AssemblyName)_MarkupCompiler.Cache для поддержания текущего состояния компилятора.

• Файл $(AssemblyName)_MarkupCompiler.lref для кэширования файлов XAML со ссылками на локально определенные типы.

Ниже приведен набор правил, управляющих инкрементным построением:

• Файл является наименьшей единицей, в которой система построения обнаруживает изменения. Таким образом, для файла кода система построения не может определить, был ли изменен тип или добавлен код. То же самое касается и файлов проекта.

• Механизм инкрементного построения должен знать, определяет ли страница XAML класс или использует другие классы.

• При изменении Reference перекомпилируются все страницы.

• При изменении файла кода перекомпилируются все страницы с локально определенными ссылками типа.

• При изменении файла XAML:

  • Если XAML объявлен в проекте как Page: если XAML не имеет локально определенных ссылок типа, перекомпилируется этот XAML плюс все страницы XAML с локальными ссылками; если XAML имеет локальные ссылки, перекомпилируются все страницы XAML с локальными ссылками.

  • Если XAML объявлен в проекте как ApplicationDefinition: перекомпилируются все страницы XAML (поскольку во всех XAML есть ссылка на тип Application, который возможно был изменен).

• Если файл проекта объявляет файл кода как определение приложения вместо файла XAML:

  • Проверяется, изменилось ли значение ApplicationClassName в файле проекта (есть ли новый тип приложения?). Если это так, перекомпилируется все приложение.

  • В противном случае перекомпилируются все страницы XAML с локальными ссылками.

• При изменении файла проекта применяются все вышеперечисленные правила и проверяется, что должно быть перекомпилировано. Изменения следующих свойств приводят к полной перекомпиляции: AssemblyName, IntermediateOutputPath, RootNamespace и HostInBrowser.

Возможны следующие сценарии перекомпиляции:

• Перекомпилируется все приложение.

• Перекомпилируются только те файлы XAML, в которых есть локально определенные ссылки типа.

• Ничего не перекомпилируется (если в проекте ничего не было изменено).

См. также

Основные понятия

Развертывание приложений WPF

URI типа "pack" в Windows Presentation Foundation

Ресурсы, содержимое и файлы данных для приложений Windows Presentation Foundation

Другие ресурсы

Справочные сведения о MSBuild и Windows Presentation Foundation

Журнал изменений

Дата	Изменения	Причина
Июль 2008	Добавлены сведения о свойстве построения SplashScreen.	Изменение функции SP1.