Нин Чжан блог

Введение

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

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

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

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

Кроме 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) сначала пытается загрузить дизайн информацию о времени, как иконы (по другой именования см. в разделе Добавление панели инструментов Иконка для вашего управления 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 или смесь) не может найти соответствующее время проектирования сборки в той же директории, во время выполнения сборки, он будет искать их в папке Design, если он существует.

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

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

для выполнения сборки foo.dll, общее время сборки конструкция называется Foo.Design *. DLL, Visual Studio конкретных время сборки конструкция называется Foo.VisualStudio.Design *. DLL, а также наложения конкретных время сборки конструкция называется 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 методы) . Таким образом, мы должны знать, какие метаданные выигрывает. Самый простой и логического проектирования является последней победы. В основном, это правда, но не всегда. Иногда результат может быть не-детерминированный, когда те же метаданные времени разработки указана несколько раз, но с разными значениями.

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

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