Zhang Ning blog

Introducción

Si usted escribe los controles de Silverlight, debe considerar la escritura de diseño asambleas tiempo para los controles también, por dos razones simples:

• la productividad del desarrollador: tratar de imaginar el desarrollo de Silverlight sin necesidad de herramientas como Visual Studio o de mezcla! Para los controles personalizados, es posible que deba proporcionar gran parte de la experiencia en tiempo de diseño para los controles en Visual Studio o mezcla usted mismo.
• diseñadores: XAML y herramientas como mezcla permiten a los desarrolladores y diseñadores trabajar juntos. Un criterio clave de diseño para los controles de Silverlight es asegurarse de que los diseñadores pueden utilizarlos sin escribir una sola línea de código.

experiencia de diseño de tiempo por lo general incluye (pero no limitados a) lo siguiente:

1. Metadatos para la ventana de propiedades, como categoría, InfoTip, propiedad personalizada / unión / editores de la colección, etc
2. Metadatos para la superficie de diseño, como inicializador, Adorner, del menú contextual, adaptadores, etc
3. Caja de herramientas de integración, como los iconos, el control de registro
4. intellisense para el código de editor

Salvo intellisense (consulte Añadir Intellisense ricas para sus controles de Silverlight ) y el registro de control (consulte Registro Silverlight controles con Visual Studio y mezcla ), por encima del tiempo experiencia de diseño se entregan generalmente a través de asambleas en tiempo de diseño. A continuación voy a discutir los distintos enfoques de la entrega de experiencias en tiempo de diseño, en la complejidad y la flexibilidad, e introducir gradualmente las piezas de la convención de nomenclatura para las asambleas en tiempo de diseño.

Tiempo de ejecución única asamblea

La forma más sencilla para ofrecer experiencia en tiempo de diseño es el paquete de código de tiempo de diseño en las asambleas en tiempo de ejecución, especialmente cuando el tiempo de diseño de metadatos son significativos en tiempo de ejecución también, como TypeConverterAttribute .

Los pros y los contras de este enfoque:

• Pro: simple
  • no lo separe el asambleas en tiempo de diseño, más simple de configuración
  • atributos de tiempo de diseño se especifican directamente en el código de tiempo de ejecución, más fácil de mantener
• Con: estrecha conexión entre tiempo de ejecución y el código de tiempo de diseño
  • perf porque la degradación de código inútil tiempo de diseño en tiempo de ejecución
  • dependencias en tiempo de diseño (como MWDs y otros VS / asambleas Blend) recibe arrastrado a tiempo de ejecución sin necesidad
  • no puede dar servicio a tiempo de ejecución o tiempo de diseño independiente
  • no puede soportar múltiples diseñadores (como tanto VS2008/Blend2 y VS2010/Blend3)

Los contras son particularmente malas para Silverlight, ya que las asambleas en tiempo de diseño son en realidad. NET, con referencias a los tipos de Silverlight. Mezcla de Silverlight y. NET puede ser difícil y confusa, y puede conducir a errores sutiles. Además, las aplicaciones Silverlight son en su mayoría de aplicaciones web, de modo tamaño de la descarga y el rendimiento son particularmente importantes. Arrastrando en. NET en aplicaciones Silverlight ciertamente no ayuda. Así que este enfoque es sumamente desalentador, a menos que exista una justificación sólida para ello.

Compartidas en tiempo de diseño de la Asamblea

Así que el paso revolucionario hacia adelante es la de separar el tiempo de diseño y código de tiempo de ejecución, la liberación y de servicios con asambleas separadas. Esto abre todo tipo de posibilidades. Por supuesto, necesitamos una forma de vincular a las asambleas en tiempo de diseño a sus asambleas en tiempo de ejecución correspondiente, sin introducir ninguna dependencia innecesaria o perf la degradación de las asambleas en tiempo de ejecución. De ahí la convención de nomenclatura: si una asamblea Foo.dll tiempo de ejecución se hace referencia en un proyecto de Silverlight, el diseñador (como Visual Studio y Blend) primero intentará cargar la información en tiempo de diseño como los iconos (a través de otra convención de nomenclatura, vea Cómo agregar una caja de herramientas icono de la Silverlight Control ) y el tiempo de diseño de metadatos (a través de la interfaz, como IRegisterMetadata para VS2008 y Blend2 o IProvideAttributeTable para VS2010 y Blend3. Por favor, vea Cómo escribir Silverlight tiempo de diseño para todos los diseñadores: Visual Studio 2008, Blend 2; Blend 3, y Visual Studio 2010 ) del conjunto de tiempo de ejecución; entonces buscará un ensamblado en tiempo de diseño con el nombre Foo.Design.dll en el mismo directorio que Foo.dll; si lo encuentra, el diseñador intentará cargar la información en tiempo de diseño de foo . Design.dll también.

Diseñador de tiempo de diseño específicos de la Asamblea

Visual Studio es sobre todo para los desarrolladores, mientras que Blend es sobre todo para los diseñadores, así que tienen diferentes requisitos de experiencias en tiempo de diseño. Poner todo el código de tiempo de diseño en un ensamblado compartido tiempo de diseño introduce estrecho acoplamiento entre los diseñadores. Así que la convención de nomenclatura se ha mejorado: tiempo de ejecución para el montaje Foo.dll, hay una compartida en tiempo de diseño de montaje Foo.Design.dll que se carga por todos los diseñadores, cada diseñador también intentará cargar su diseño asambleas propio tiempo, como Foo.VisualStudio. Design.dll de Visual Studio, y Foo.Expression.Design.dll de mezcla. El diseñador de montaje específica en tiempo de diseño se carga después de la asamblea en tiempo de diseño compartido. Tercera Parte diseñadores pueden definir su propio diseñador de montaje específicos tiempo de diseño. Silverlight Toolkit versión 12 2008 utiliza esta convención de nomenclatura. Por favor, consulte Características de diseño en Silverlight Toolkit Tiempo y tiempo de diseño de funciones de aplicación de Silverlight Toolkit para más información.

Sub Diseño de carpetas

Así que para apoyar tanto a Visual Studio y Blend, tiempo de ejecución de cada asamblea tiene tres asambleas en tiempo de diseño, en el mismo directorio, y un paquete (como Silverlight SDK o kit de herramientas de Silverlight ) por lo general contiene varios ensamblados en tiempo de ejecución. Así que el directorio se hace un poco apretado. Una pequeña mejora es poner las asambleas en tiempo de diseño en una subcarpeta de diseño. Así que la convención de nombres es aún mayor: si un diseñador (como Visual Studio o de mezcla) no puede encontrar correspondientes asambleas en tiempo de diseño en el mismo directorio como un ensamblado en tiempo de ejecución, se buscará en la subcarpeta de diseño, si es que existe.

Compatibilidad con múltiples versiones de MWDs

El tiempo de diseño se construyen en la parte superior del marco de extensibilidad de diseño , que consta de varias dlls como Microsoft.Windows.Design.Extensibility.dll y Microsoft.Windows.Design.Interaction.dll. Por lo general, los llaman colectivamente como MWDs. Para hacer la vida más interesante, a veces tenemos que introducir cambios importantes al marco de extensibilidad, como VS2008 y el uso Blend2 MWD versión 3.5, VS2010 y el uso Blend3 MWD versión 4.0, y son incompatibles. Así que si tienes una asamblea Foo.dll tiempo de ejecución, y desea que sus usuarios sean capaces de desarrollar en contra de ella con las dos VS2008 y VS2010, usted tiene que proporcionar dos tipos de asambleas en tiempo de diseño: un sistema construido contra v3.5 MWDs y usados por VS2008, y otro conjunto construido contra v4.0 MWD y utilizada por VS2010. Los dos conjuntos de asambleas en tiempo de diseño probablemente tiene una gran cantidad de código en común, mientras que el de VS2010 puede tener algún nuevo código para aprovechar las nuevas funcionalidades expuestas por VS2010. Desde las asambleas en tiempo de diseño se cargan por su nombre y no se puede tener dos archivos con el mismo nombre, por lo que la convención de nomenclatura se ha mejorado una vez más:

para un tiempo de ejecución de montaje Foo.dll, la asamblea en tiempo de diseño para compartir, se llama Foo.Design *. dll, el Visual Studio específicas de montaje en tiempo de diseño se llama Foo.VisualStudio.Design *. dll, y la combinación específica de montaje en tiempo de diseño se denomina de Foo . Expression.Design *. dll, donde * puede ser cero o más caracteres válidos para nombres de archivo. Cuando un diseñador (como Visual Studio o Blend) intenta cargar un ensamblado en tiempo de diseño y ajuste de varios de la convención de nomenclatura, cero o uno se cargará:

• Si la versión del MWD referencia el tiempo de montaje diseño tiene un gran número de versión diferente de la versión de MWD el diseñador, entonces el tiempo de montaje de diseño no se carga y se omite.
• Si hay más de uno en tiempo de diseño de montaje es compatible con la versión de MWD el diseñador, el diseñador de las cargas un compilado con la versión más alta que MWD es menor o igual a la versión de MWD el diseñador.

Silverlight Toolkit 3 10 2009 Lanzamiento utiliza esta convención de nomenclatura para apoyar tanto a VS2008 y Blend3/VS2010. Por favor, consulte tiempo de diseño de Silverlight: Octubre 2009 Kit de herramientas de actualización de la publicación , Cómo escribir tiempo de diseño de Silverlight para todos los diseñadores: Visual Studio 2008, Blend 2; Blend 3, y Visual Studio 2010 , y extensibilidad de la serie - WPF y Silverlight de código de tiempo la distribución de Diseño - Parte I más información.

Apoyo Ambos WPF y Silverlight

Para complicar aún más la vida, ya que WPF y Silverlight son tan terriblemente similar, puede tener la tentación de tratar de escribir una vez y ejecutar tanto con WPF y Silverlight. Usted no está solo. Hay muchos artículos sobre cómo compartir el código fuente y / o binarios a través de Silverlight y WPF. Nos gustaría hacer eso por las asambleas en tiempo de diseño también, es decir, tienen el mismo diseño asambleas tiempo tanto para WPF y Silverlight controles. Un enfoque es hacer que la mayor parte del tiempo de diseño asambleas agnóstica plataforma y plataforma específica límite (WPF o Silverlight) Código y las referencias a un conjunto específico de la plataforma pequeña. Silverlight 3 SDK RDA 2 (instalado por VS2010 automáticamente también) utiliza este enfoque para DataGrid diseñador (hay un System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll en el directorio SDK). Por favor, consulte la extensibilidad de la serie - WPF y Silverlight en tiempo de diseño de código compartido - Parte I para más información.

El último gana

Los metadatos diseño mismo tiempo para una clase o de sus miembros se pueden especificar varias veces en múltiples asambleas en tiempo de diseño, que permite el montaje en tiempo de diseño para compartir, para especificar por defecto / comportamiento común y, a continuación diseñador asambleas en tiempo de diseño específicas para anularla en caso necesario. Los metadatos diseño mismo tiempo también se pueden especificar varias veces dentro de un conjunto de diseño sola vez (consulte tiempo de diseño de funciones de aplicación de Silverlight Toolkit como un ejemplo, donde DescriptionAttribute para una clase o de su propiedad puede ser añadido por AddDescriptions, AddAttributes y métodos AddTables) . Así que tenemos que saber lo que gana metadatos. El diseño más simple y más lógica es último gana. Esto es sobre todo cierto, pero no siempre. A veces el resultado puede ser no-determinista cuando los metadatos en tiempo de diseño se especifica la misma varias veces, pero con valores diferentes.

Realimentación

El tiempo de diseño parece fácil, pero el diablo está en los detalles! Comentarios siempre son apreciados. Por favor, hágamelo saber lo que te encuentras con problemas, lo que pide o mejoras que le gustaría hacer, tanto para el diseño de experiencia y un marco de extensibilidad tiempos de diseño. Gracias!