Нин Чжан блог

Введение

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

• производительность труда разработчиков: попробуйте представить себе Silverlight развития без таких инструментов, как Visual Studio или смесь! Для пользовательских элементов управления, возможно, придется предоставить значительную часть опыта время разработки для элементов управления в Visual Studio или смесь самостоятельно.
• дизайнеры: XAML и инструменты, такие как смесь позволяет разработчикам и дизайнерам работать вместе. Ключевые критерии дизайна для Silverlight контроля, чтобы убедиться, дизайнеры могут использовать их без написания единой строчки кода.

Опыт проектирования обычно включает в себя (но не ограничиваются) следующее:

1. Метаданные для окна свойств, как категории, всплывающую подсказку, пользовательские свойства / обязательный / коллекции редакторы и т.д.
2. Метаданные для конструктора, как инициализатор, декоративных элементов, контекстное меню, адаптеры и т.д.
3. Панель инструментов интеграции, как и иконы, контроль регистрации
4. IntelliSense для редактора кода

Кроме IntelliSense (см. Добавить Богатые Intellisense для элементов управления Silverlight ) и контроль регистрации (см. Регистрация Silverlight управления с Visual Studio и смешивания ), над дизайном опыт времени, как правило, доставляются через сборках время разработки. Ниже я расскажу о различных подходах доставки опыт проектирования, в возрастающей сложности и гибкости, и постепенно ввести куски именования для сборок время разработки.

Время Ассамблеи только

Простейший способ доставки опыт проектирования является пакет норм проектирования время в среде выполнения сборки, особенно, когда метаданные времени разработки имеют смысл во время выполнения тоже, как TypeConverterAttribute .

Плюсы и минусы такого подхода:

• Pro: простое
  • нет отдельного проектирования сборок, простой установки
  • Атрибуты времени разработки указаны непосредственно на время выполнения кода, проще в обслуживании
• Против: тесная связь времени выполнения и кода время разработки
  • перфорация деградации из-за бесполезных тайм-кода дизайна во время выполнения
  • время разработки зависимостей (например, ММР и другие VS / Blend сборок) получить втянуты в среде выполнения излишне
  • не может обслуживать выполнения, или время разработки самостоятельно
  • не может поддерживать несколько дизайнеров (например, как VS2008/Blend2 и VS2010/Blend3)

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

Общие Ассамблеи время разработки

Так революционным шагом вперед является разделение время проектирования и выполнения кода, выпуска и обслуживания их отдельных узлов. Это открывает все виды возможностей. Конечно, нам нужен способ связать сборки время разработки с соответствующими сборках среды выполнения, без введения каких-либо ненужных зависимостей или перфорация деградации выполнения сборки. Следовательно, соглашение об именах: если во время выполнения foo.dll сборке имеется ссылка в проекте Silverlight, дизайнер (например, Visual Studio и Blend) сначала пытается загрузить время разработки информации, такой как иконки (при помощи другого именования, см. в разделе Добавление Toolbox Иконка для вашего управления Silverlight ) и время разработки метаданных (через интерфейс, как и IRegisterMetadata для VS2008 и Blend2 или IProvideAttributeTable для VS2010 и Blend3 Пожалуйста, смотрите. Как писать Silverlight время разработки для всех дизайнеров: Visual Studio 2008, Blend 2, Blend 3, и Visual Studio 2010 ) от выполнения сборки, он будет искать сборку время разработки под названием Foo.Design.dll в том же каталоге, foo.dll, если он найден, дизайнер будет пытаться загрузить информацию о конструкции время от Foo . Design.dll также.

Конструктор Конкретные Ассамблеи Время дизайна

Visual Studio в основном для разработчиков, в то время как смесь в основном для дизайнеров, так что они имеют разные требования к опыте проектирования. Помещение всех норм проектирования время в одной общей сборки время проектирования вводит тесной связи между дизайнерами. Так именования усиливается: для сборки foo.dll выполнения, есть общее время разработки сборки Foo.Design.dll это загружены все дизайнеры, каждый дизайнер будет также пытаться загрузить свои собственные сборки времени дизайн, как и Foo.VisualStudio. Design.dll для Visual Studio, и Foo.Expression.Design.dll для Blend. Дизайнер конкретных время сборки дизайн загружается после общей сборки время проектирования. В-третьих дизайнеров партия может определять свои собственные дизайнер конкретных время сборки конструкции. Silverlight Toolkit декабря 2008 Релиз использует это соглашение об именах. Пожалуйста, смотрите время разработки возможности в Silverlight Toolkit и время разработки функций реализации в Silverlight Toolkit для получения дополнительной информации.

Дизайн подпапку

Таким образом, чтобы поддерживать как Visual Studio и Blend, каждое время выполнения сборки состоит из трех сборках время разработки, в том же каталоге, а также пакет (например, Silverlight SDK или Silverlight Toolkit ) обычно содержит несколько выполнения сборки. Так каталога становится немного тесно. Незначительное улучшение это поставить сборках время разработки под дизайн вложенной папке. Так именования еще более усиливается: если дизайнер (например, Visual Studio или Blend) не может найти соответствующее время сборки проекта в том же каталоге, выполнения сборки, он будет искать их в дизайн вложенной папке, если он существует.

Поддержка нескольких версий ММР

Дизайн времени построен на вершине дизайнер расширения основы , которая состоит из нескольких библиотек, как Microsoft.Windows.Design.Extensibility.dll и Microsoft.Windows.Design.Interaction.dll. Мы обычно называем их под общим названием ММР. Чтобы сделать жизнь более интересной, иногда мы должны ввести критические изменения в рамках расширения, как и VS2008 и Blend2 использовать MWD версии 3.5, VS2010 и Blend3 использовать MWD версии 4.0, и они несовместимы. Так что если у вас есть время выполнения foo.dll сборки, и вы хотите, чтобы ваши пользователи могли развивать с ней как с VS2008 и VS2010, вы должны предоставить два комплекта агрегатов время разработки: один набор встроенных против v3.5 ММР и используется по VS2008, и другой набор встроенных против v4.0 MWD и используются VS2010. Два комплекта агрегатов время разработки, вероятно, много кода, в общем, в то время как по одному для VS2010 может иметь некоторые новом коде использовать новые функциональные возможности, предоставляемые VS2010. После сборки время разработки загружаются по имени и вы не можете иметь два файла с одинаковым именем, так именования усиливается еще раз:

для выполнения сборки foo.dll, общей сборки время проектирования называется Foo.Design *. DLL, Visual Studio конкретных время сборки конструкция называется DLL *. Foo.VisualStudio.Design, и смесь конкретных время сборки конструкция названа Foo . Expression.Design *. DLL, где * может быть ноль или более допустимых символов для имен файлов. Когда дизайнер (например, Visual Studio или Blend) пытается загрузить сборку время разработки и несколько соответствовать соглашению об именах, ноль или один будет загружен:

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

Silverlight 3 Toolkit октября 2009 релиз использует это соглашение об именах для поддержки как VS2008 и Blend3/VS2010. Пожалуйста, смотрите Silverlight время разработки: Инструментарий октября 2009 Выпуск обновлений , Как писать Silverlight время разработки для всех дизайнеров: Visual Studio 2008, Blend 2, Blend 3, а также Visual Studio 2010 , а также расширения серии - WPF и Silverlight Дизайн-Time Code Sharing - Часть I дополнительной информации.

Поддержка как WPF и Silverlight

Чтобы усложнить жизнь дальше, так как WPF и Silverlight настолько ужасно похожи, вы можете захотеть попробовать написать его один раз и работать как с WPF и Silverlight. Вы не одиноки. Есть много статей о том, как предоставить исходный код и / или файлы через Silverlight и WPF. Мы хотели бы сделать, что для сборки тоже время разработки, то есть имеют одинаковый дизайн время сборки для WPF и Silverlight контроля. Один из подходов заключается, чтобы сделать большую часть времени разработки агностиком платформ сборки, а также ограничить платформе (WPF или Silverlight) кода и ссылок на небольшой платформе конкретные сборки. Silverlight 3 SDK ГДР 2 (устанавливается по VS2010 автоматически тоже) использует этот подход для DataGrid дизайнер (есть System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll в каталоге SDK). Пожалуйста, смотрите расширения серии - WPF и Silverlight Дизайн-Time Code Sharing - Часть I для получения дополнительной информации.

Последнее Один Победы

Же метаданные времени разработки для класса или отдельного его члена может быть указана несколько раз в различных сборках время разработки, что позволяет общей сборки время разработки, чтобы указать по умолчанию / общее поведение, а затем дизайнер конкретных сборках время проектирования, чтобы переопределить его при необходимости. Же метаданные времени разработки также могут быть указаны несколько раз в одну сборку время проектирования (см. Дизайн Время выполнения функций в Silverlight Toolkit в качестве примера, где DescriptionAttribute для класса или его имущества могут быть добавлены AddDescriptions, AddAttributes и AddTables методы) . Так что мы должны знать, какие метаданные выигрывает. Самый простой и логического проектирования является последней победы. Это в основном верно, но не всегда. Иногда результат может быть просто не детерминированный, когда же метаданные время проектирования задается несколько раз, но с разными значениями.

Обратная связь

Дизайн времени звучит просто, но дьявол кроется в деталях! Отзывы всегда приветствуется. Пожалуйста, дайте мне знать, какие вопросы у вас возникли, какие запросы / улучшения, которые вы хотели бы сделать, как раз опыт проектирования и рамки дизайнер расширяемости. Спасибо!