Глава 2. Создание приложения Longhorn

 

введение
главе 1. Модель приложения Longhorn

Глава 2. Создание приложения Longhorn

Брент Настойт
Мудрый овся консультации

Ноябрь 2003 г.

Содержание

Подсистема сборки Microsoft .NET: MSBuild.exe
Создание Hello World с помощью MSBuild
Терминология MSBuild
Создание исполняемого приложения Longhorn
Создание сборки библиотеки Longhorn
Создание документа Longhorn
XAML-файл в виде объявления класса
Манифест приложения
Манифест развертывания
Запуск приложения
Зачем создавать еще одну систему сборки?
Сводка

Чтобы создать приложение Longhorn, необходимо установить пакет SDK (SDK) Longhorn. Кроме того, можно установить выпуск Microsoft® Visual Studio®, поддерживающий Longhorn. В этой книге я не обсуждаю использование Visual Studio, так как его мастера, функции создания кода фантазии и возможности сборки проектов не соответствуют тому, что на самом деле происходит под обложками. Я считаю, что вы должны понять, что инструмент делает для вас, прежде чем полагаться на инструмент.

При установке пакета SDK Longhorn создается набор элементов меню "Пуск", которые можно использовать для создания сеанса командной строки, в котором можно создавать приложения Longhorn. Чтобы создать отладочные версии приложения в 32-разрядной системе Microsoft Windows® XP, перейдите по следующим пунктам меню, чтобы создать соответствующий сеанс командной строки:

• Начало
• Программ
• Microsoft Longhorn SDK
• Открытие окна среды сборки
• Среда сборки Windows XP 32-разрядной версии
• Настройка среды сборки Windows XP 32 (отладка)

Подсистема сборки Microsoft .NET: MSBuild.exe

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

MSBuild /?

При выполнении MSBuild без каких-либо аргументов командной строки, как показано здесь, он выполняет поиск в текущем рабочем каталоге для имени файла, который заканчивается именем proj, например proj, CSPROJ и т. д. Когда он находит его, он создает проект в соответствии с директивами в этом файле.

MSBuild

При наличии нескольких файлов проекта в каталоге можно указать соответствующий файл проекта в командной строке:

MSBuild <ProjectName>.proj

Как правило, MSBuild создает целевой объект по умолчанию в файле проекта. Вы можете переопределить это и указать целевой объект, который требуется создать. Например, чтобы создать целевой объект с именем CleanBuild, необходимо вызвать MSBuild следующим образом:

MSBuild /t:Cleanbuild

Создание Hello World с помощью MSBuild

Рассмотрим файлы, необходимые для создания простого приложения Hello World на основе навигации. Позже я подробно охарактеризую назначение и использование каждого файла.

Сначала необходимо определить объект Application. Это происходит в файле, который обычно называется файлом определения приложения . Этот файл HelloWorldApplication.xaml определяет объект Application.

HelloWorldApplication.xaml

<NavigationApplication xmlns="https://schemas.microsoft.com/2003/xaml" 
                       StartupUri="HelloWorld.xaml" />

Это определение говорит: "Для объекта приложения я хочу использовать экземпляр класса MSAvalon.Windows.Navigation.NavigationApplication. При запуске приложение должно перейти и отобразить пользовательский интерфейс, определенный в файле HelloWorld.xaml".

Ниже приведено содержимое файла HelloWorld.xaml. Это немного более интересная версия предыдущего примера Hello World в главе 1.

HelloWorld.xaml

<Border xmlns="https://schemas.microsoft.com/2003/xaml">
  <FlowPanel>
    <SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>   </FlowPanel>
</Border>

Теперь, когда у меня есть весь код для простого приложения Hello World, мне нужен файл проекта, определяющий, как создать приложение. Вот мой файл HelloWorld.proj.

HelloWorld.proj

<Project DefaultTargets="Build">
  <PropertyGroup>
    <Property Language="C#" />   
    <Property DefaultClrNameSpace="IntroLonghorn" />
    <Property TargetName="HelloWorld" />
  </PropertyGroup>

  <!--Imports the target which contains all the common targets-->
  <Import Project="$(LAPI)\WindowsApplication.target" />

  <ItemGroup>
    <!-- Application markup -->
    <Item Type="ApplicationDefinition" Include="HelloWorldApplication.xaml" />
   
    <!-- Compiled Xaml Files list -->
    <Item Type="Pages" Include="HelloWorld.xaml"/>      
  </ItemGroup>
</Project>

Поместите эти три файла в каталог. Откройте командную строку пакета SDK Longhorn, перейдите в каталог, содержащий файлы, и запустите MSBuild. Он компилирует программу в исполняемый файл.

Далее в этой главе мы рассмотрим содержимое файла определения приложения. В главе 3 я подробно описываю многие из элементов языка разметки расширяемых приложений (XAML), которые можно использовать для определения пользовательского интерфейса. Прежде чем подробно ознакомиться с файлом проекта, давайте рассмотрим некоторые терминологии MSBuild.

Терминология MSBuild

Давайте установим определения для некоторых элементов MSBuild. свойства — это пара "ключ-значение". Значение свойстваможет исходить из переменной среды, из коммутатора командной строки или из определения свойства свойства в файле проекта, как показано ниже:

<Property OutputDir="bin\" />

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

<Item Type="Compile" Include="*.cs" Exclude="DebugStuff.cs" />

задача является атомарным блоком в процессе сборки. задачи могут принимать входные параметры из элементов свойств , элементов элементов или простых строк. Имя задачи определяет тип данных сборки .NET, необходимый для выполнения задачи . задачи могут выдавать элементов, которые используют другие задачи. MSBuild включает множество задач, все из которых могут быть широко классифицированы как

• Задачи средства .NET
• Задачи развертывания
• Задачи оболочки

Например, t задачи с именем Csc вызывает компилятор C# в качестве средства сборки. который компилирует все элементы item, указанные в атрибут е источников (который задает элементы item с типа компиляции) в сборку, и создает сборку в виде выходного элемента.

<Task Name="Csc" AssemblyName="$(OutputDir)\HelloWorld.exe"
                 Sources="@(Compile)" />

Целевой — это один логический шаг процесса сборки. Target может выполнять анализ метки времени. Это означает, что Целевой не будет выполняться, если это не требуется. Целевой выполняет одну или несколько задачдля выполнения необходимых операций, как показано ниже.

<Target Name="CopyToServer"
        Inputs="$(OutputDir)\HelloWorld.exe"
        Outputs="\\DeployServer\$(BuildNum)\HelloWorld.exe"
        DependsOnTargets="Compile">

  <Task Name="Copy" ... />
</Target>

Атрибут условия примерно эквивалентен простому , если оператор. Условие может сравнить две строки или проверить наличие файла или каталога. Вы можете применить condition к любому элементу в файле проекта. Например, вот группа свойств, определяемых только в том случае, если свойство конфигурации имеет значение Отладка:

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

импорта примерно эквивалентен инструкции #include C/C++, как показано в следующем примере. При импорте проекта содержимое импортированного проекта логически становится частью импортируемого проекта.

<Import Project="$(LAPI)\WindowsApplication.target" />

Теперь, когда терминология выходит за пределы пути, давайте рассмотрим типичный файл проекта.

Создание исполняемого приложения Longhorn

Вот простой, но относительно комплексный файл проекта, который создает исполняемое приложение Longhorn:

<Project DefaultTargets="Build">
  <PropertyGroup>
    <Property Language="C#" />
    <Property DefaultClrNameSpace="IntroLonghorn" />
    <Property TargetName="MyApp" />
  </PropertyGroup>

  <Import Project="$(LAPI)\WindowsApplication.target" />

  <ItemGroup>
    <Item Type="ApplicationDefinition" Include="MyApp.xaml" />

    <Item Type="Pages" Include="HomePage.xaml" />
    <Item Type="Pages" Include="DetailPage.xaml" />
    <Item Type="Code" Include="DetailPage.xaml.cs"/>

    <Item Type="DependentProjects" Include="MyDependentAssembly.proj" /> 

    <Item Type="Components" Include="SomeThirdParty.dll" />

    <Item Type="Resources" Include="Picture1.jpg"
          FileStorage="embedded" Localizable="False"/>
    <Item Type="Resources" Include="Picture2.jpg"
          FileStorage="embedded" Localizable="True"/>
  </ItemGroup>
</Project>

Элемент project

Все файлы проекта начинаются с определения корневого элемента с именем Project. Его атрибут DefaultTargets указывает имена целевых объектов, которые система должна создавать, если не указать целевой объект. В этом примере я указываю, что по умолчанию система должна создать целевой объект с именем Build.

Элементы PropertyGroup и Property

Правила сборки могут условно выполняться на основе значений свойств. Как упоминалось, значение свойства может исходить из переменной среды, из коммутатора командной строки MSBuild или из определения свойства в файле проекта.

Проект приложения должен указывать как минимум значение свойств Language и TargetName. В этом примере я указываю, что язык — C# и имя итогового приложения должно быть MyApp. Я также назначил значение свойству с именем DefaultClrNameSpace.

Система сборки компилирует каждый XAML-файл в определение управляемого класса. По умолчанию управляемый класс будет иметь то же имя, что и имя базового файла исходного файла XAML. Например, файл Markup.xaml компилируется в определение класса с именем Markup. Задав свойство DefaultClrNameSpace значение IntroLonghorn, я запрашиваю систему сборки для префикса созданных имен классов с помощью пространства имен IntroLonghorn. Из-за этого система сборки создает класс с именем IntroLonghorn.Markup для определения Markup.xaml.

Я определил свои свойства перед импортом других проектов, поэтому правила импортированных проектов будут использовать указанные значения свойств, например, я получаю правильные правила сборки для приложений C#, так как я определяю свойство language как C#.

Элемент импорта

Правила в целевом объекте сборки сборки создают исполняемый файл приложения Longhorn. Указание этих правил сборки в каждом файле проекта будет емким и повторяющимся. Поэтому немного позже в файле проекта я использую следующее определение для импорта предопределенного файла проекта с именем WindowsApplication.target:

  <Import Project="$(LAPI)\WindowsApplication.target" />

Этот импортированный файл содержит стандартные правила сборки для создания приложения Windows, и он (косвенно) определяет целевой объект с именем сборки.

Элементы элемента ItemGroup и

Элемент ItemGroup и дочерние элементы Item определяют все части, необходимые для сборки приложения.

У вас должен быть один элемент с типа ApplicationDefinition, как показано здесь. Этот элемент указывает файл, описывающий объект приложения приложения. Объект приложения обычно является экземпляром класса MSAvalon.Windows.Application или класса MSAvalon.Windows.Navigation.NavigationApplication, как описано далее в этой главе.

<Item Type="ApplicationDefinition" Include="MyApp.xaml" />

Каждый элемент с типа pages определяет набор ФАЙЛОВ XAML, как показано здесь. Система сборки компилирует эти определения XAML в классы, которые он включает в результирующую сборку.

<Item Type="Pages" Include="HomePage.xaml" />
<Item Type="Pages" Include="DetailPage.xaml" />

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

<Item Type="Code" Include="DetailPage.xaml.cs"/>

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

<Item Type="DependentProjects" Include="MyDependentAssembly.proj" /> 

Код в этом проекте может использовать типы в предварительно созданной сборке, также называемой сборкой компонентов. Для компиляции кода с помощью таких сборок компонентов компилятору требуется ссылка на каждую сборку. Кроме того, при развертывании приложения необходимо также развернуть эти сборки компонентов. Вы перечисляете каждую сборку компонента с помощью элемента с типа компонентов:

<Item Type="Components" Include="SomeThirdParty.dll" />

Ссылка на сборку отличается от сборки компонента. В обоих случаях код использует типы в предварительно созданной сборке. Однако вы не отправляете ссылку на сборку как часть приложения, в то время как вы отправляете сборку компонента как часть приложения. Система сборки должна знать это различие.

Вы указываете элемент с типом ссылок , чтобы указать, что компилятор должен ссылаться на указанную сборку во время сборки, как показано здесь, но сборка не будет частью развертывания приложения. Система сборки автоматически включает ссылки на стандартные системные сборки, например mscorlib.dll, System.dll, PresentationFramework.dll. и многое другое, но вам придется добавить любую нестандартную сборку, которую приложение должно ссылаться.

<Item Type="References" Include="SharedThirdParty.dll" />

Приложение также может использовать ресурсы. Элемент с типом ресурсов описывает ресурс, используемый приложением, как показано здесь. Система сборки может внедрить ресурс в результирующую сборку или включить его в виде автономного файла. Система сборки также может поместить локализованные ресурсы в вспомогательные сборки.

<Item Type="Resources" Include="Picture1.jpg"
      FileStorage="embedded" Localizable="False"/>
<Item Type="Resources" Include="Picture2.jpg"
      FileStorage="embedded" Localizable="True"/>

Создание сборки библиотеки Longhorn

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

• Проект библиотеки задает значение свойства TargetType значением библиотеки.
• Обычно проект библиотеки не включает элемент определения приложения.

Ниже приведен пример файла проекта, создающего библиотеку:

<Project DefaultTargets="Build">
  <PropertyGroup>
    <Property Language="C#" />
    <Property DefaultClrNameSpace="IntroLonghorn" />
    <Property TargetName="MyLibrary" />
    <Property TargetType="Library" />
  </PropertyGroup>

  <Import Project="$(LAPI)\WindowsApplication.target" />

  <ItemGroup>
    <Item Type="Pages" Include="ErrorPage.xaml" />
    <Item Type="Code" Include="ErrorPage.xaml.cs"/>
    <Item Type="Code" Include="Utilities.cs"/>

    <Item Type="DependentProjects" Include="MyDependentAssembly.proj" /> 

    <Item Type="Components" Include="SomeThirdParty.dll" />

    <Item Type="Resources" Include="Picture1.jpg"
          FileStorage="embedded" Localizable="False"/>
    <Item Type="Resources" Include="Picture2.jpg"
          FileStorage="embedded" Localizable="True"/>
  </ItemGroup>
</Project>

Создание документа Longhorn

Вы не ограничиваетесь созданием приложений с помощью XAML. Вы также можете использовать XAML-файлы для создания высокоинактивного, интеллектуально отрисованного, адаптивного документа для чтения пользователем. В этом случае файлы XAML вместе представляют страницы документа. Для создания таких документов можно использовать подсистему MSBuild.

Изменения в файле проекта для создания документа вместо приложения являются незначительными:

• Задайте для свойства targetType значение свойства TargetType, чтобы Document.
• Импортируйте проект WindowsDocument.target для соответствующих правил сборки.
• Включите все остальные файлы проекта как обычно.

Важно понимать, что TargetTypeDocument действительно создает. При сборке documentвыходные данные сборки — это файл контейнера, а система сборки оптимизирует содержимое контейнера для загрузки, а не скорости. Файл контейнера — это расширение структурированного хранилища Windows, также известное как DocFile, формат. Обработка контейнеров Longhorn предоставляет функции, позволяющие отрисовке частично загруженных файлов. Поэтому перед запуском приложения не требуется весь контейнер, скачанный.

Кроме того, при запросе MSBuild создать файл контейнера он компилирует каждый XAML-файл в двоичное представление XML, называемого двоичным XAML (BAML). BAML является гораздо более компактным, чем исходный текстовый файл или скомпилированныйto-IL сборке. BAML-файлы загружаются быстрее — оптимизированы для скачивания, но интерпретатор должен анализировать их во время выполнения, чтобы создавать экземпляры классов, описанных в файле. Поэтому такие файлы не оптимизированы для скорости. До сих пор я создал скомпилированныеto-IL файлы (также известные как CAML-файлы, а не скомпилированные XAML).

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

<Project DefaultTargets="Build">
  <PropertyGroup>
    <Property TargetType="Document" />
      <Property Language="C#" />
      <Property DefaultClrNameSpace="IntroLonghorn" />
      <Property TargetName="MyDocument" />
  </PropertyGroup>
    
  <Import Project="$(LAPI)\WindowsDocument.target" />

  <ItemGroup>
    <Item Type="ApplicationDefinition" Include="MyApp.xaml" />

    <Item Type="Pages" Include="Markup.xaml" />
    <Item Type="Pages" Include="Navigate.xaml" />
    <Item Type="Code" Include="Navigate.xaml.cs"/>

    <Item Type="Resources" Include="Picture1.jpg"
          FileStorage="embedded" Localizable="False"/>
    <Item Type="Resources" Include="Picture2.jpg"
          FileStorage="embedded" Localizable="True"/>
  </ItemGroup>
</Project>

Теперь, когда вы узнали, как создать различные типы приложений и компонентов Longhorn, давайте рассмотрим ФАЙЛЫ XAML более подробно. В частности, давайте рассмотрим, что делает система сборки при превратив XAML-файл в класс .NET.

XAML-файл в виде объявления класса

Файл определения приложения — это XAML-файл, определяющий класс объекта приложения. Однако в целом документ XAML — это просто файл, определяющий класс. Класс, созданный определением XAML, является производным от класса, связанного с именем корневого элемента XML-документа. По умолчанию система сборки использует имя базового файла XAML в качестве созданного имени класса.

Создание файла определения приложения для приложения навигации

Помните, что элемент элемента Type ApplicationDefinition указывает имя XAML-файла, определяющего объект приложения . Другими словами, этот элемент указывает XAML-файл, содержащий точку входа для приложения. Платформа Longhorn создаст экземпляр MSAvalon.Windows.Applicationпроизводного типа, который определяется в этом файле и позволяет управлять запуском, завершением работы и навигацией приложения.

В главе 1 вы узнали, как создавать и использовать экземпляр приложения программным способом. Следующий XAML-файл использует разметку для определения объекта приложения для проекта:

<NavigationApplication xmlns="https://schemas.microsoft.com/2003/xaml" 
                       StartupUri="HelloWorld.xaml" />

Я ожидаю, что большинство приложений Longhorn будут приложениями на основе навигации, и поэтому часто будет повторно использовать стандартный объект NavigationApplication. Вы можете повторно использовать этот файл определения приложения для большинства приложений на основе навигации, изменив только значение атрибута StartupUri.

Например, если предыдущее определение приложения находится в файле HelloWorldApplication.xaml, и я использую файл проекта HelloWorld.proj, указанный ранее, система сборки создает следующее объявление класса:

namespace IntroLonghorn {
  class HelloWorldApplication :
           MSAvalon.Windows.Navigation.NavigationApplication {
.
.
.
   }
 }

Пространство имен приводит к объявлению defaultClrNameSpace в файле проекта, объявленное имя класса совпадает с именем базового файла, а объявленный класс расширяет класс, представленный корневым элементом в XAML-файле.

Настройка созданного кода с помощью атрибутов

При объявлении корневого элемента в XAML-файле можно использовать атрибуты корневого элемента для управления именем созданного объявления класса. Вы можете использовать любой из следующих необязательных атрибутов:

• Определение префикса пространства имен, которое связывает префикс с пространством имен с именем Определение. Для этого пространства имен необходимо определить префикс для использования атрибутов языка и класса . Традиционно используется префикс def.
• Атрибут языка (определенный в пространстве имен определения ), указывающий язык программирования, используемый любым встроенным кодом в XAML-файле.
• Атрибут класса (определенный в пространстве имен определения ), указывающий имя созданного класса. При указании имени, содержащего один или несколько периодов, система сборки не префиксирует имя со значением DefaultClrNameSpace.

Например, давайте изменим содержимое файла HelloWorldApplication.xaml следующим образом:

<NavigationApplication xmlns="https://schemas.microsoft.com/2003/xaml"
                       xmlns:def="Definition"
                       def:Class="Special.MyApp"
                       def:CodeBehind="HelloWorldApplication.xaml.cs" 
                       StartupUri="HelloWorld.xaml" />

Затем созданный класс будет следующим:

namespace Special {
  class MyApp :
           MSAvalon.Windows.Navigation.NavigationApplication {
.
.
.
  }
}

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

Практически всем приложениям потребуется написать код( например, обработчик событий щелчка для кнопки или виртуального метода переопределения) помимо разметки, указывающей пользовательский интерфейс. Помните из главы 1, что мое приложение, не основанное на навигации, перекроет метод OnStartingUp, чтобы создать его окно и элементы управления. Я перезаписаю этот пример, чтобы проиллюстрировать, как объединить код приложения и разметку.

Хотя в этом предстоящем примере создается приложение, отличное от навигации, я хочу подчеркнуть, что на самом деле нет убедительных причин для создания такого приложения. Вы всегда можете создать приложение на основе навигации, которое никогда не переходит на другую страницу. Однако написание такого приложения требует, чтобы я смешивал код и разметку в одном классе, поэтому предоставляет хороший пример.

Помните, что для создания приложения, отличного от навигации, необходимо определить пользовательский класс, наследуемый от MSAvalon.Windows.Application и переопределяющий метод OnStartingUp. Файл определения приложения объявляет класс объектов приложения, который использует программа. Поэтому приложение, отличное от навигации, должно определить его переопределение метод OnStartingUp в том же классе.

За исключением следующих изменений, файл конфигурации приложения для приложения, отличного от навигации, содержит те же элементы, что и файл определения для приложения навигации:

• Корневой элемент — Application вместо NavigationApplication.
• Файл должен содержать или ссылаться на реализацию метода OnStartingUp для класса приложения.

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

Связывание файла Source-Behind с XAML-файлом

Часто требуется разрабатывать части приложения с помощью разметки и разрабатывать другие части с помощью более традиционного языка программирования. Настоятельно рекомендуется разделять пользовательский интерфейс и логику на отдельные исходные файлы с помощью следующего метода.

Вы можете добавить элемент XAML CodeBehind (определенный в пространстве имен определения ) в корневой элемент любого ФАЙЛА XAML и указать имя файла исходного кода (также известного как файл кода за). Подсистема сборки компилирует объявления XAML в управляемый класс. Система сборки также компилирует файл программной части в объявление управляемого класса. Сложный аспект заключается в том, что оба из этих объявлений класса представляют частичные объявления одного класса.

Ниже приведено определение XAML, которое создает класс приложения без навигации, эквивалентный первому примеру в главе 1:

<Application xmlns="https://schemas.microsoft.com/2003/xaml"
             xmlns:def="Definition"
             def:Language="C#"
             def:Class="IntroLonghorn.CodeBehindSample"
             def:CodeBehind="CodeBehind.xaml.cs" />

В этом файле определения приложения есть два важных аспекта:

• Атрибут языка указывает, что файл кода программной части содержит исходный код C#.
• Атрибут CodeBehind указывает, что имя исходного файла CodeBehindMySample2.xaml.cs.

Ниже приведен соответствующий исходный файл:

namespace IntroLonghorn {
  using System;
  using MSAvalon.Windows;
  using MSAvalon.Windows.Controls;
  using MSAvalon.Windows.Media;

  public partial class CodeBehindSample {
    MSAvalon.Windows.Controls.SimpleText txtElement;
    MSAvalon.Windows.Window              mainWindow;

    protected override
    void OnStartingUp (StartingUpCancelEventArgs e) {
      base.OnStartingUp (e);
      CreateAndShowMainWindow ();
    }

    private void CreateAndShowMainWindow () {
      // Create the application's main window
      mainWindow = new MSAvalon.Windows.Window ();

      // Add a dark red, 14 point, "Hello World!" text element
      txtElement = new MSAvalon.Windows.Controls.SimpleText ();
      txtElement.Text = "Hello World!";
      txtElement.Foreground = new
       MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
      txtElement.FontSize = new FontSize (14,
                                          FontSizeType.Point);
      mainWindow.Children.Add (txtElement);
      mainWindow.Show ();
    }
  }
}

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

Сочетание исходного кода и разметки в одном XAML-файле

Я думаю, что это просто неправильно смешивать исходный код и разметку в том же файле. Я даже не считал, как это сделать. Тем не менее, некоторый злодея где-то напишет пример программы с помощью этого метода, поэтому вам может потребоваться понять, что он сделал. Кроме того, вы можете использовать подход к файлу кода, описанный ранее, чтобы избавить мир от небольшого количества зла и отделить пользовательский интерфейс от логики.

Ниже приведен файл определения приложения с исходным кодом, вставленным непосредственно в разметку:

<Application xmlns="https://schemas.microsoft.com/2003/xaml"
    xmlns:def="Definition"
    def:Language="C#"
    def:Class="IntroLonghorn.MySample2" >

  <def:Code>
  <![CDATA[
    protected override void OnStartingUp (StartingUpCancelEventArgs e) {
      base.OnStartingUp (e);
      CreateAndShowMainWindow ();
    }
    . . . Remaining methods elided for clarity
  ]]>
  </def:Code>
</Application>

В этом примере атрибут языка указывает, что встроенный исходный код — C#. Обратите внимание, что элемент Code Code является блоком CDATA, содержащим встроенный исходный код. Иногда технически необходимо заключить встроенный исходный код в блок XML CDATA, чтобы убедиться, что документ хорошо сформирован. На самом деле средство синтаксического анализа XAML всегда требует, чтобы встроенный исходный код был заключен в блок CDATA, даже если он не создает хорошо сформированный документ.

Я извиняюсь еще раз за то, что показываю вам такую предательство.

Манифест приложения

При компиляции приложения MSBuild создает файл .exe плюс два файла манифеста: манифест приложения, *.manifest и манифест развертывания *.deploy. Эти манифесты используются при развертывании приложения или документа с сервера. Сначала скопируйте приложение, все его зависимости и два файла манифеста в соответствующее расположение на сервере. Во-вторых, измените манифест развертывания, чтобы он указывает на расположение манифеста приложения.

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

HelloWorld.manifest

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
          xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd">

  <assemblyIdentity name="HelloWorld" version="1.0.0.0"
                    processorArchitecture="x86" asmv2:culture="en-us"
                    publicKeyToken="0000000000000000" />

  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2"
              dependencyName="HelloWorld">

    <commandLine file="HelloWorld.exe" parameters="" />
  </entryPoint>

  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" version="1" 
                       ID="SeeDefinition">
          <IPermission 
            class="System.Security.Permissions.FileDialogPermission"
            version="1" Unrestricted="true" />
          <IPermission 
            class="System.Security.Permissions.IsolatedStorageFilePermission" 
            version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission
            class="System.Security.Permissions.SecurityPermission"
            version="1" Flags="Execution" />
          <IPermission
            class="System.Security.Permissions.UIPermission" version="1"
            Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission
            class="System.Security.Permissions.PrintingPermission"
            version="1" Level="SafePrinting" />
          <IPermission
            class="MSAvalon.Windows.AVTempUIPermission, PresentationFramework,
                   Version=6.0.4030.0, Culture=neutral,
                   PublicKeyToken=a29c01bbd4e39ac5" version="1"
                   NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>

        <AssemblyRequest name="HelloWorld"
                         PermissionSetReference="SeeDefinition" />
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>

  <dependency asmv2:name="HelloWorld">
    <dependentAssembly>
      <assemblyIdentity name="HelloWorld" version="0.0.0.0"
                        processorArchitecture="x86" />
    </dependentAssembly>

    <asmv2:installFrom codebase="HelloWorld.exe"
                       hash="5c58153494c16296d9cab877136c3f106785bfab" 
                       hashalg="SHA1" size="5632" />
  </dependency>
</assembly>

Большая часть содержимого манифеста приложения должна быть относительно очевидной. Элемент entryPoint указывает имя метода точки входа, основнойи ссылается на зависимостис именем HelloWorld, содержащей точку входа. Элемент entryPoint также содержит имя программы и аргумент командной строки, необходимый оболочке для запуска приложения.

Элемент зависимостей HelloWorldHelloWorld содержит сведения (элемент зависимыхAssembly), указывающий зависимые сборки и элемент installFrom , указывающий загрузчику, где найти файл сборки и исходный хэш файла. Загрузчик может использовать хэш для обнаружения изменений, внесенных в сборку после компиляции.

Диспетчер доверия Longhorn использует элемент TrustInfo для определения необходимых приложению разрешений безопасности. В предыдущем примере приложение HelloWorld определяет набор разрешений, которые он называет набор разрешений SeeDefinition набор разрешений. Сразу после определения набора разрешений элемент AssemblyRequest запрашивает, что сборка с именем HelloWorld получает по крайней мере набор разрешений в наборе с именем SeeDefinition. Разрешения в этом примере обычно предоставляются приложениям, работающим в SEE, поэтому приложение Hello World запускается без отображения пользователю предупреждений системы безопасности Диспетчера доверия.

Манифест развертывания

Как уже упоминалось, манифест развертывания более интересен. Манифест развертывания содержит достаточно параметров, которые управляют развертыванием приложения.

HelloWorld.deploy

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" 
          xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"  
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd">
  
  <assemblyIdentity name="HelloWorld.deploy" version="1.0.0.0" 
                    processorArchitecture="x86" asmv2:culture="en-us" 
                    publicKeyToken="0000000000000000" />

  <description asmv2:publisher="Wise Owl, Inc." 
               asmv2:product="Brent's HelloWorld Application"            
    asmv2:supportUrl="http://www.wiseowl.com/AppServer/HelloWorld/support.asp" 
  />
  
  <deployment xmlns="urn:schemas-microsoft-com:asm.v2" 
              isRequiredUpdate="false">
    <install shellVisible="true" />
    <subscription>
      <update>
        <beforeApplicationStartup />
        <periodic>
          <minElapsedTimeAllowed time="6" unit="hours" />
          <maxElapsedTimeAllowed time="1" unit="weeks" />
        </periodic>
      </update>
    </subscription>
  </deployment>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity name="HelloWorld" version="1.0.0.0" 
                        processorArchitecture="x86" asmv2:culture="en-us" 
                        publicKeyToken="0000000000000000" />
    </dependentAssembly>
    <asmv2:installFrom codebase="HelloWorld.manifest" />
  </dependency>
</assembly>

Манифест развертывания содержит сведения, необходимые Longhorn для установки и обновления приложения. Обратите внимание, что элемент assemblyIdentity манифеста развертывания ссылается на манифест приложения. В конце концов манифест приложения уже описывает все компоненты приложения. Чтобы установить приложение, манифест развертывания говорит: "Вот описание файлов, которые необходимо установить.

Конечно, при установке приложения вам также потребуется больше сведений, чем только файлы для копирования в систему. В описании перечисленыиздателя , продукта и атрибуты supportUrl; Система отображает содержимое в диалоговом окне "Добавление и удаление программ".

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

Запуск приложения

Как правило, пользователь будет запускать манифест приложения для выполнения приложения с сервера непосредственно без установки приложения на локальном компьютере. Longhorn загружает компоненты приложения по мере необходимости. В этом случае сервер должен быть доступен для запуска приложения.

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

При первом запуске манифеста развертывания Longhorn устанавливает приложение в кэше приложений и добавляет запись в список "Добавление или удаление программ" панели управления. Впоследствии при запуске манифеста развертывания приложение загружается непосредственно из кэша приложений. Обычно он не скачан снова.

Однако при удалении приложения из кэша с помощью applet панели управления "Добавление и удаление программ", последующее выполнение манифеста развертывания скачивает и устанавливает приложение еще раз.

Кроме того, можно изменить номер версии приложения на сервере. Затем при запуске манифеста развертывания Longhorn скачивает и устанавливает новую версию параллельно с текущей версией. Обе версии приложения будут отображаться в списке "Добавление или удаление программ".

Зачем создавать еще одну систему сборки?

Мне очень нравится MSBuild, хотя в момент написания этой статьи у меня было всего несколько недель опыта с ним. Конечно, годы опыта работы с makefiles делают все более элегантной системой сборки привлекательной. В настоящее время существуют две альтернативные системы сборки в общем использовании— Make и Ant. Кажется естественным сравнить MSBuild с такими альтернативами.

Почему бы не использовать?

Зачем разрабатывать новую систему сборки, когда многие разработчики знакомы с существующим именем Make? Создание плохой интеграции средств в систему сборки. Просто выполните команды оболочки. Из-за этого во время процесса сборки не существует присущей одному инструменту связи с другим инструментом. MSBuild создает экземпляры классов задач и задачи могут взаимодействовать между собой, передавая обычные типы .NET.

Makefiles имеют необычный синтаксис, трудно писать и не масштабироваться, так как они получают сложные для больших проектов. Кроме того, средства, отличные от Make, не могут легко обработать файл makefile. Средства, отличные от MSBuild, могут легко создавать и анализировать синтаксис на основе XML проекта MSBuild.

Наконец, Make на самом деле не поддерживает проекты. Нет абстракции файловой системы и нет поддержки каскадных свойств. Кроме того, нет поддержки времени разработки для создания файла makefile.

Почему не использовать муравей?

Аналогичный часто задаваемый вопрос заключается в том, почему разработка новой системы сборки на основе XML, когда существует существующая очень успешная и богатая система под названием Ant? Ant — это система сборки с открытым исходным кодом из Apache.org, которая в качестве атомарной операции сборки была пионером xml-файлов проектов и задач. Существует также отличный порт .NET Ant под названием NAnt, доступный из nant.sourceforge.net. На поверхности MSBuild и Ant/NAnt похожи. Оба средства используют XML в качестве формата сериализации проекта, и оба средства используют задачи в качестве атомарной единицы операции сборки. Оба инструмента имеют свои сильные стороны, но при более внимательном взгляде они имеют разные цели проектирования.

Ant принял решение о разработке, чтобы разместить большую функциональность в большом наборе задач. MSBuild имеет другую цель проектирования, где аналогичная функциональность инкапсулируется подсистемой (например, анализ меток времени, взаимодействие между элементами, пакетной обработкой задач, преобразованиями элементов и т. д.). Оба подхода имеют свои сильные и слабые стороны.

Модель Ant позволяет разработчикам расширять и контролировать каждую деталь сборки, поэтому она очень гибкая. Тем не менее, она также несет большую ответственность за средства записи задач, так как задачи должны быть гораздо более сложными для обеспечения согласованной функциональности. Модель MSBuild уменьшает объем функциональных возможностей, необходимых каждой задаче. Поэтому авторы проекта могут полагаться на согласованные функциональные возможности различных проектов, целевых объектов и задач. Кроме того, интегрированные среды разработки, такие как Visual Studio, также могут полагаться на эти службы, чтобы обеспечить согласованные результаты и широкий пользовательский интерфейс, не зная ничего о внутренних задачах, вызываемых во время процесса сборки.

Аналогичным образом, хотя Ant имеет концепцию скрипта сборки, он не имеет концепции манифеста проекта, который имеет MSBuild. Скрипт сборки говорит, как создать набор файлов, но не предоставляет дополнительную семантику, описывающую использование файлов. Манифест также описывает семантику файлов, которая позволяет дополнительным средствам, таким как интегрированная среда разработки, более глубоко интегрироваться с системой сборки. И наоборот, отсутствие манифеста проекта означает, что разработчик может проще адаптировать Ant для создания новых типов "вещи", так как для скрипта сборки нет ограничивающей схемы.

Сводка

Теперь вы освоили основы. Вы можете написать XAML и скомпилировать, развернуть и запустить итоговое приложение. К сожалению, приложения, которые вы научились писать до сих пор довольно скучно. главе 3 подробно описывает XAML и показывает, как использовать широкий спектр объектов пользовательского интерфейса, предоставляемых платформой Longhorn. В последующих разделах показано ряд других новых технологий, которые также можно использовать в приложениях.

перейти к главе 3. Элементы управления и XAML.