Нин Чжан блог

Введение

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

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

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

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

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

Runtime Ассамблеи только

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

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

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

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

Общий дизайн Время Ассамблеи

Так революционный шаг вперед, чтобы отделить затраты времени и времени выполнения кода, выпуск и обслуживание их отдельных узлов. Это открывает все виды возможностей. Конечно, нам нужен способ связать узлы время разработки своих соответствующих собраний исполнения, без введения каких-либо ненужных зависимостей или перфорация деградации среды выполнения сборки. Таким образом, соглашение об именовании: если во время выполнения собраний Foo.dll упоминается в проект Silverlight, дизайнер (например, Visual Studio и Blend) будет первой попытке загрузить проектирования информации, например, иконы (при помощи другого именования, см. Как Добавить Toolbox Icon для вашего Silverlight Control ) и время разработки метаданных (через интерфейс, как и 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 в основном для разработчиков, в то время как Blend в основном для разработчиков, поэтому они имеют различные требования для приобретения опыта проектирования. Ввод весь код, дизайн один раз в общих собраний время разработки вводит жесткие связи между дизайнерами. Так именования усиливается: для выполнения собраний Foo.dll, есть общий дизайн время сборки Foo.Design.dll, загружаемый для всех дизайнеров, каждый дизайнер будет пытаться загрузить свой собственный дизайн время собраний, как Foo.VisualStudio. Design.dll для Visual Studio, а также для Foo.Expression.Design.dll Blend. Дизайнер конкретных время сборки дизайн загружается после общих собраний времени дизайн. Третьих лиц дизайнеры могут определять свои собственные дизайнер конкретных время монтажа конструкции. Silverlight Инструментарий декабря 2008 Выпуск использует этот именования. Пожалуйста, см. Дизайн время возможности в Silverlight Инструментарий и Дизайн Время выполнения функций в Silverlight Инструментарий для получения дополнительной информации.

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

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

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

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

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

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

Silverlight 3 Инструментарий октября 2009 Выпуск использует этот именования для поддержки как и VS2008 Blend3/VS2010. Пожалуйста, см. Дизайн Время Silverlight: Инструментарий октября 2009 Выпуск обновления , Как писать Silverlight Дизайн времени для всех дизайнеров: Visual Studio 2008, Blend 2; Blend 3, а также Visual Studio 2010 , и расширяемости серии - WPF и Silverlight Design-Time кодекса Обмен - Часть 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 Design-Time код-шеринговых - Часть I для получения дополнительной информации.

Последний выигрывает

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

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

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