Нашли ошибку или опечатку? Выделите текст и нажмите

Поменять цветовую

гамму сайта?

Поменять
Обновления сайта
и новые разделы

Рекомендовать в Google +1

Компиляция и развертывание приложений Silverlight

115

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

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

При компиляции проекта Silverlight в программе Visual Studio используется тот же компилятор csc.exe, что и в полнофункциональных приложениях .NET. Отличие лишь в том, что в данном случае компилятор обращается к другим сборкам. Программа Visual Studio передает компилятору в командной строке флаг nostdlib, который запрещает компилятору использовать стандартную библиотеку, определенную в файле mscorlib.dll.

Таким образом, приложение Silverlight компилируется как обычное приложение .NET, написанное на стандартном языке C#. Ограничивается лишь набор библиотек, содержащих стандартные классы. По сравнению с JavaScript модель компиляции Silverlight имеет ряд преимуществ, включая легкость развертывания и повышенную производительность.

Скомпилированная сборка Silverlight содержит код и документы XAML для каждой страницы приложения. Эти компоненты включены в сборку как ресурсы, благодаря чему коды обработки событий не могут быть отделены от разметки пользовательского интерфейса. Разметка XAML не компилируется (в отличие от разметки WPF, которая преобразуется в оптимизированный формат BAML).

Проект Silverlight компилируется в файл .dll, который получает имя проекта. Например, если проект называется SilverlightApplication1, компилятор csc.exe создает файл SilverlightApplication1.dll. Сборка проекта сохраняется в папке Bin\Debug, которая находится в папке проекта вместе с несколькими важными файлами (они перечислены ниже):

  • Файл .pdb содержит информацию, необходимую для отладчика Visual Studio. Его имя совпадает с именем проекта (например, SilverlightApplication1.pdb).

  • Файл AppManifest.xaml. В этом файле перечислены зависимые сборки.

  • Зависимые сборки. Папка Bin\Debug содержит сборки, используемые в проекте Silverlight (если свойствам Copy Local этих сборок присвоено значение true). Свойства Copy Local базовых сборок Silverlight имеют значение false, поскольку их не нужно развертывать с приложением. Чтобы изменить значение Copy Local, откройте окно Solution Explorer (Обозреватель решений), разверните узел References (Ссылки), выделите сборку и отредактируйте значение в окне свойств.

  • Файл TestPage.html является начальной страницей, которую пользователь запрашивает для запуска приложения Silverlight.

  • Файл .хар содержит пакет Silverlight, предоставляющий все, что нужно для развертывания приложения, включая манифест, сборку проекта и другие сборки, используемые в приложении. При создании приложения Silverlight, хостируемого страницей ASP.NET, файл .хар копируется также в папку ClientBin на тестовом веб-сайте.

С помощью вкладки свойств проекта Visual Studio можно изменить имена сборки, пространства имен (используемого при добавлении новых файлов с исходными кодами), файла .хар и т.п. Чтобы открыть вкладку свойств, дважды щелкните в узле Properties (Свойства) окна Solution Explorer:

Вкладка свойств проекта Visual Studio

Развертывание приложения Silverlight

Понимая модель компиляции приложения Silverlight, несложно понять модель его развертывания. Ключевой элемент модели развертывания — файл ХАР, объединяющий все компоненты приложения (манифест и сборки) в одном контейнере.

Технически файл ХАР является архивным. Чтобы убедиться в этом, переименуйте его (например, SilverlightSample.xap на SilverlightSample.xap.zip). Открыв файл .zip с помощью любого архиватора, можно увидеть хранящиеся в нем файлы. На рисунке ниже показано содержимое файла .хар, используемого в приведенном выше примере. Данный файл содержит манифест и сборку приложения. Если приложение содержит сборки дополнений (например, System.Windows.Controls.dll), они тоже хранятся в файле ХАР.

Содержимое файла XAP

Использование файла XAP предоставляет два очевидных преимущества:

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

  • Упрощение развертывания. Когда приложение Silverlight готово к развертыванию, достаточно скопировать на сервер файл ХАР и тестовый файл TestPage.html (или любой другой файл HTML, в котором определена область содержимого Silverlight). Отслеживать сборки и ресурсы нет необходимости.

Благодаря модели ХАР, развертывание простого приложения Silverlight заключается всего лишь в копировании двух файлов. Для хостинга приложения Silverlight достаточно сделать файл ХАР доступным для клиента, чтобы он мог загрузить его в браузер и выполнить на локальном компьютере.

Декомпиляция приложения Silverlight

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

  1. Загрузите входную страницу.

  2. Откройте исходный код страницы и найдите элемент <param>, указывающий на файл ХАР.

  3. Введите запрос к файлу ХАР в адресной строке браузера. Оставьте текущий домен, но замените имя страницы частичным маршрутом, указывающим на файл ХАР.

  4. Выберите команду Save As (Сохранить как) и сохраните файл ХАР локально.

  5. Переименуйте файл ХАР, добавив расширение .zip. Откройте архив и извлеките сборку проекта. Эта сборка такая же, как и в любом приложении .NET. Как и обычная сборка .NET, она содержит код IL.

  6. Откройте сборку проекта в любом декомпиляторе (например, в Reflector или ILSpy). Просмотрите код IL и внедренные ресурсы. Можете преобразовать код IL в код C#.

Декомпиляция Silverlight

Конечно, многие разработчики Silverlight не одобряют подобные методы, точно так же, как разработчики .NET не одобряют декомпиляцию их мощных клиентских приложений конечными пользователями. Однако возможность декомпиляции — неизбежный побочный эффект модели Silverlight, с которым приходится мириться.

Код IL легко декомпилировать в C#, поэтому в нем нельзя хранить секретную информацию (например, ключи, пароли, патентованные алгоритмы и т.п.). Если некоторую задачу нужно решить с помощью секретного кода, внедрите в приложение Silverlight вызов веб-службы. Чтобы любопытные пользователи и зловредные конкуренты не заглядывали в ваш код и не копировали ваши методы, можете также применить обфускатор (obfuscator) — программу, которая автоматически перемешивает имена и компоненты структуры скомпилированного кода, не изменяя его поведение. В рабочей среде Visual Studio можно воспользоваться упрощенным вариантом обфускатора, который называется Dotfuscator. Доступно также множество коммерческих обфускаторов.

Базовые сборки Silverlight

Платформа Silverlight содержит подмножество классов полнофункциональной инфраструктуры .NET Framework. Втиснуть в Silverlight всю библиотеку .NET Framework было бы невозможно, поскольку загружаемый дистрибутив Silverlight имеет объем всего 5 Мбайт, однако Silverlight все же поддерживает существенную и наиболее важную часть классов .NET Framework.

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

mscorlib.dll

Эквивалент сборки mscorlib.dll полнофункциональной платформы .NET Framework. Представленное в Silverlight подмножество содержит следующие компоненты: базовые типы данных, исключения, интерфейсы и классы пространства имен System; обычные и обобщенные коллекции; классы, управляющие файлами; классы, поддерживающие глобализацию, интроспекцию, отладку, потоки и управление ресурсами.

System.dll

Эта сборка содержит дополнительные обобщенные коллекции, а также классы обработки адресов URI и регулярных выражений.

System.Core.dll

та сборка обеспечивает поддержку технологии LINQ. Ее имя совпадает с именем аналогичной сборки полнофункциональной платформы .NET Framework.

System.Net.dll

Классы, поддерживающие работу в сети, загружающие вебстраницы и создающие сокетные соединения.

System.Windows.dll

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

System.Windows.Browser.dll

Классы, обеспечивающие взаимодействие с элементами HTML.

System.Xml.dll

Минимальный набор классов, необходимых для обработки документов XML — классы XmlReader и XmlWriter.

Некоторые компоненты сборок Silverlight доступны только для скрытого кода .NET Framework и не могут вызываться непосредственно в исходном коде. Эти компоненты отмечены специальным атрибутом SecurityCritical. Однако атрибут SecurityCritical не выводится в браузере объектов, поэтому с его помощью нельзя выяснить, какие средства можно использовать в приложении Silverlight. Вам остается только попробовать применить выбранное средство.

Если попытаться применить компонент, отмеченный атрибутом SecurityCritical, будет сгенерировано исключение securityException. Например, доступ к файловой системе разрешен приложению Silverlight только посредством программного интерфейса изолированного хранилища или класса OpenFileDialog. По этой причине в класс FileStream добавлен атрибут SecurityCritical.

Сборки дополнений Silverlight

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

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

Ниже перечислены наиболее часто используемые дополнительные сборки:

System.Windows.Controls.dll

Содержит несколько новых элементов управления, включая Calendar, DatePicker, TabControl и GridSplitter.

System.Windows.Controls.Data.dll

Содержит новый, разработанный с нуля, класс DataGrid (идеальный инструмент для вывода плотно заполненных решеток данных) и класс DataPager, предоставляющий возможность разбивать результаты на отдельные страницы.

System.Windows.Controls.Data.Input.dll

Содержит несколько элементов управления (Label, DescriptionViewer и ValidationSummary), которые полезны при создании форм, связанных с данными.

System.Windows.Controls.Navigation.dll

Содержит элементы управления Frame и Page, на основе которых создается навигационная система Silverlight.

System.Windows.Controls.Input.dll

Содержит класс AutoCompleteBox — текстовое поле, выводящее список подсказок при вводе данных пользователем.

Все указанные сборки содержат дополнительные элементы управления. В ближайшем будущем Microsoft планирует создать много новых дополнений. Соответственно количество элементов управления, предоставляемых в дополнениях, существенно превзойдет количество базовых элементов управления, предоставляемых в надстройке Silverlight. Загрузить их можно с сайта http://codeplex.com/Silverlight.

При перетаскивании элемента управления из сборки на страницу Silverlight рабочая среда Visual Studio автоматически добавляет ссылку на сборку. Если выбрать ссылку и посмотреть на нее в окне свойств, можно увидеть, что свойству Copy Local присвоено значение true, что отличает сборку дополнения от сборок надстройки, входящих в базовый набор Silverlight. В результате этого при компиляции приложения сборка дополнения будет внедрена в окончательный пакет. Рабочая среда Visual Studio достаточно интеллектуальна, чтобы распознать сборку, не входящую в базовый набор. Даже если добавить сборку вручную, ее свойству Сору Local автоматически будет присвоено значение true.

Кэширование сборок

Кэширование — это технология развертывания, позволяющая исключить зависимые сборки из файла ХАР. Вместо развертывания зависимых сборок с файлом ХАР разместите их в отдельном файле ZIP в той же папке. Цель состоит в том, чтобы уменьшить время запуска приложения, предоставив клиенту возможность кэшировать копии часто используемых сборок.

По умолчанию приложение Silverlight, создаваемое программой Visual Studio, не сконфигурировано на кэширование сборок. Для включения кэширования дважды щелкните на узле Properties (Свойства) в окне Solution Explorer. В открывшемся окне свойств проекта установите флажок Reduce ХАР size by using application library caching (Уменьшение размера файла ХАР путем кэширования библиотеки приложения):

Включение кэширования в Silverlight

Чтобы увидеть результаты, перекомпилируйте приложение, щелкните на кнопке Show All Files (Показать все файлы), расположенной в заголовке окна Solution Explorer, и разверните папку Bin\Debug. В ней вы увидите файл ZIP для каждой кэшируемой сборки. Например, если в приложении применяется сборка System.Windows.Controls.dll, рядом с файлом ХАР будет приведено имя файла System.Windows.Controls.zip. Этот файл содержит сжатую копию сборки System.Windows.Controls.dll. При этом указанная сборка будет исключена из файла ХАР.

Архивные файлы зависимых сборок, поддерживающих кэширование

Кэширование сборок уменьшает размер файла XAP. Чем меньше размеры файлов, тем быстрее они загружаются. Уменьшение файла ХАР уменьшает время запуска приложения. Однако при первой загрузке кэширование не улучшает производительность, потому что необходимо загрузить не только сокращенный файл ХАР, но и файлы ZIP, содержавшие зависимые сборки. Общее время загрузки данных остается тем же.

Преимущество кэширования проявляется, когда пользователь возвращается к приложению во второй раз. При этом браузер загружает файл ХАР, извлекая зависимые сборки из кэша. Загружать повторно архивные файлы зависимых сборок не нужно.

Чтобы как можно более эффективно применять кэширование сборок, учитывайте следующее:

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

  • При каждом запуске приложения клиентом браузер проверяет, существуют ли новые версии кэшированных сборок. Обнаружив новую версию, браузер загружает ее и замещает ею предыдущую кэшированную версию.

  • Если одно приложение загружает сборку и помещает ее в кэш браузера, другое приложение, в котором включено кэширование сборок, может использовать ее.

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

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

Пройди тесты