Blog Ning Zhang

Introducción

Si usted escribe los controles de Silverlight, se debe considerar la escritura asambleas en tiempo de diseño 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, puede que tenga que proporcionar gran parte de la experiencia de tiempo de diseño para los controles en Visual Studio o mezcla de uno mismo.
• diseñadores: XAML y herramientas como mezcla de permitir a los desarrolladores y diseñadores trabajar juntos. A criterio de diseño clave para los controles de Silverlight es hacer que los diseñadores pueden utilizar sin necesidad de escribir una sola línea de código.

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

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

Excepto intellisense (consulte Agregar Intellisense ricas para sus controles Silverlight ) y el control de registro (consulte Registrar controles Silverlight con Visual Studio y Blend ), sobre la experiencia en tiempo de diseño generalmente se entregan 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 tiempo de diseño.

Sólo en tiempo de ejecución de la Asamblea

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

Los pros y los contras de este enfoque:

• Pro: simple
  • no separar las asambleas en tiempo de diseño, configuración sencilla
  • atributos en tiempo de diseño se especifican directamente en el código de tiempo de ejecución, más fácil de mantener
• En contra: estrecho acoplamiento de tiempo de ejecución y el código de tiempo de diseño
  • perf degradación a causa de código inútil el tiempo de diseño en tiempo de ejecución
  • dependencias en tiempo de diseño (como el MWD y otras asambleas VS / Mezcla) ser arrastrado en tiempo de ejecución sin necesidad
  • no puede dar servicio en tiempo de ejecución o de 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 que el tamaño de descarga y el rendimiento son particularmente importantes. Arrastrando en. NET en aplicaciones Silverlight ciertamente no ayuda. Por lo que este enfoque es sumamente desalentador, a menos que exista una justificación fuerte para él.

Diseño compartido Tiempo de montaje

Por lo que el avance revolucionario es disociar el tiempo de diseño y tiempo de ejecución de código, la liberación y de servicios con asambleas separadas. Esto abre todo tipo de posibilidades. Por supuesto, necesitamos una forma de vincular las asambleas en tiempo de diseño a sus asambleas en tiempo de ejecución correspondiente, sin introducir ninguna dependencia innecesaria o la degradación de perforación a las asambleas en tiempo de ejecución. De ahí que la convención de nomenclatura: si un conjunto de Foo.dll tiempo de ejecución se hace referencia en un proyecto de Silverlight, el diseñador (como Visual Studio y Blend) primero se carga 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 para el control de Silverlight ) y los metadatos en tiempo de diseño (a través de la interfaz, como IRegisterMetadata para VS2008 y Blend2 o IProvideAttributeTable para VS2010 y Blend3 Por favor vea. Cómo Escribir Tiempo Silverlight Diseño para todos los diseñadores: Visual Studio 2008, Blend 2, Blend 3, y Visual Studio 2010 ) de la asamblea en tiempo de ejecución, sino que se buscará un conjunto de tiempo de diseño por el Foo.Design.dll nombre en el mismo directorio que Foo.dll, si lo encuentra, el diseñador se carga la información en tiempo de diseño de foo . Design.dll así.

Diseñador de diseño específico Tiempo de montaje

Visual Studio es principalmente para los desarrolladores, al mismo tiempo de mezcla es principalmente para los diseñadores, por lo que tienen requisitos diferentes para las experiencias tiempo de diseño. Poner todo el código de tiempo de diseño en un ensamblado compartido tiempo de diseño presenta apretado acoplamiento entre los diseñadores. Así que la convención de nombres se ha mejorado: para Foo.dll montaje tiempo de ejecución, hay un tiempo compartido diseño Foo.Design.dll asamblea que se carga por todos los diseñadores, cada diseñador también intentará cargar sus propias asambleas tiempo de diseño, como Foo.VisualStudio. Design.dll para Visual Studio, y Foo.Expression.Design.dll de mezcla. El diseñador de montaje específica tiempo de diseño se carga después de la asamblea en tiempo de diseño compartido. Diseñadores de terceros pueden definir su propio diseñador de montaje específico tiempo de diseño. Silverlight Toolkit diciembre 2008 Release está utilizando esta convención. Por favor, vea Características de tiempo de diseño de Silverlight Toolkit y tiempo de diseño implementación de características de Silverlight Toolkit para más información.

Diseño Sub Folder

Así que para apoyar tanto a Visual Studio y Blend, cada asamblea de tiempo de ejecución de tres conjuntos de 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 conjuntos de tiempo de ejecución. Por lo que el directorio se hace un poco abarrotado. Una pequeña mejora es poner a las asambleas de 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 de tiempo de diseño en el mismo directorio que una asamblea de tiempo de ejecución, que se verá por ellos en la subcarpeta de diseño, si es que existe.

El apoyo de varias versiones de MWD

Tiempo de diseño se basan en la parte superior del marco de diseño de ampliación , que consta de varios archivos DLL como Microsoft.Windows.Design.Extensibility.dll y Microsoft.Windows.Design.Interaction.dll. Por lo general, los llaman colectivamente como MWD. Para hacer la vida más interesante, a veces tenemos que introducir cambios importantes en el marco de extensibilidad, como VS2008 y Blend2 uso MWD la versión 3.5, VS2010 y Blend3 uso MWD versión 4.0, y que son incompatibles. Así que si usted tiene un conjunto de Foo.dll tiempo de ejecución, y desea que sus usuarios sean capaces de desarrollar en su contra con VS2008 y VS2010 tanto, usted tiene que proporcionar dos tipos de conjuntos de tiempo de diseño: un conjunto integrado contra v3.5 MWD y se utiliza por VS2008, y otro conjunto integrado contra la MWD y utilizada por VS2010 v4.0. Los dos conjuntos de conjuntos de tiempo de diseño, probablemente tienen una gran cantidad de código en común, mientras que el de VS2010 puede tener un código nuevo 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 nombres se ha mejorado una vez más:

a una asamblea en tiempo de ejecución Foo.dll, el diseño de conjuntos de tiempo compartido se llama Foo.Design *. dll, el Visual Studio específicos de montaje tiempo de diseño se llama Foo.VisualStudio.Design *. dll, y la mezcla específica de montaje tiempo de diseño es el nombre 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 varias ajuste la convención de nombres, cero o uno se va a cargar:

• Si la versión del MWD referencia el ensamblado en tiempo de diseño tiene un número diferente de versión mayor que la versión MWD del diseñador, el ensamblado en tiempo de diseño no se carga y se pasa por alto.
• Si más de un diseño en tiempo de montaje es compatible con la versión MWD del diseñador, el diseñador carga el compilado con la versión más alta MWD que es menor o igual a la versión MWD del diseñador.

Kit de herramientas de Silverlight 3 octubre 2009 versión utiliza esta convención de nomenclatura para apoyar tanto a VS2008 y Blend3/VS2010. Por favor, vea Tiempo Silverlight Diseño: Kit de herramientas de octubre 2009 Actualización de publicación , Cómo Escribir Tiempo Silverlight Diseño para todos los diseñadores: Visual Studio 2008, Blend 2, Blend 3, y Visual Studio 2010 , y extensibilidad de la Serie - WPF y Silverlight en tiempo de diseño de código compartido - Parte I más información.

Apoyo WPF y Silverlight

Para complicar aún más la vida, ya que WPF y Silverlight son tan terriblemente similar, usted puede estar tentado a tratar de escribir una vez y ejecutar 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 tiempo de diseño también, es decir, tienen el mismo diseño de las asambleas de tiempo para WPF y Silverlight controles. Un enfoque consiste en hacer que la mayoría de los agnósticos tiempo de diseño de plataforma asambleas, y la plataforma de un límite específico (WPF o Silverlight) de código y las referencias a un conjunto específico de la plataforma pequeña. Silverlight 3 SDK GDR 2 (instalado VS2010 automáticamente también) utiliza este enfoque para el DataGrid diseñador (hay un System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll en el directorio SDK). Por favor vea extensibilidad de la Serie - WPF y Silverlight en tiempo de diseño de código compartido - Parte I para más información.

Un último gana

El diseño de metadatos 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 común para especificar default / comportamiento común y de diseño específico asambleas tiempo de diseño para reemplazar si es necesario. El diseño de metadatos mismo tiempo también se puede especificar varias veces dentro de un conjunto de diseño único momento (por favor vea Implementación de funciones de tiempo de diseño de Silverlight Toolkit como un ejemplo, donde DescriptionAttribute para una clase o su propiedad puede ser añadido por AddDescriptions, AddAttributes y métodos AddTables) . Así que tenemos que saber que los metadatos gana. El diseño más simple y lógica de la mayoría es el ú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 el mismo varias veces, pero con diferentes valores.

Realimentación

Tiempo de diseño parece fácil, pero el diablo está en los detalles! Reacciones siempre son apreciados. Por favor, hágamelo saber qué problemas te encuentras, lo que las solicitudes / mejoras que le gustaría hacer, tanto para el diseño de la experiencia los tiempos y el marco de la extensibilidad de diseño. Gracias!