Поделиться через

Компиляция приложения WPF

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

Создание приложения WPF

Приложение WPF можно скомпилировать следующим образом:

Конвейер сборки WPF

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

Процесс сборки WPF

Инициализации предварительной сборки

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

  • Платформа .NET Framework.

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

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

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

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

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

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

Компиляция разметки— pass 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). Класс объявляется с помощью модификатора partial в C# (Extends в Visual Basic), чтобы указать на то, что существует другое объявление этого класса в другом месте, обычно в связанном с кодом файле 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);
}

Public Sub InitializeComponent() _

    If _contentLoaded Then
        Return
    End If

    _contentLoaded = True
    Dim resourceLocater As System.Uri = _
        New System.Uri("mainwindow.xaml", System.UriKind.Relative)

    System.Windows.Application.LoadComponent(Me, resourceLocater)

End Sub

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

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

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

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

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

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

Базовая компиляция

Основной шаг компиляции включает компиляцию файлов кода. Это организуется логикой в целевых файлах, специфичных для языка, Microsoft.CSharp.targets и Microsoft.VisualBasic.targets. Если эвристический анализ показал, что достаточно одного прохода компилятора разметки, создается основная сборка. Однако если один или несколько ФАЙЛОВ XAML в проекте имеют ссылки на локальные типы, то создается временный .dll файл, чтобы конечные сборки приложений могли быть созданы после завершения второй передачи компиляции разметки.

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

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

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

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

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

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

Поддержка инкрементной сборки

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

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

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

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

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

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

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

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

  • Если XAML-файл изменяется:

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

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

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

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

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

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

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

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

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

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

См. также

  • Last updated on