Ning Zhang Blog

Introduction

Si vous écrivez des contrôles Silverlight, vous devriez envisager d'écrire assemblées au moment du design pour vos contrôles trop, pour deux raisons simples:

• la productivité du développeur: essayez d'imaginer le développement Silverlight sans outils comme Visual Studio ou Blend! Pour les contrôles personnalisés, vous devrez peut-être de fournir une grande partie de l'expérience de la conception de vos contrôles dans Visual Studio ou vous mélanger.
• designers: XAML et des outils comme Blend permettre aux développeurs et aux concepteurs de travailler ensemble. A des critères de conception clés pour les contrôles Silverlight est de s'assurer que les concepteurs peuvent les utiliser sans écrire une seule ligne de code.

L'expérience du temps de conception comprend généralement (mais non limité à) ce qui suit:

1. Métadonnées pour fenêtre de propriétés, comme catégorie, InfoTip, propriété personnalisée / fixation / collection monteurs, etc
2. Métadonnées pour aire de conception, comme initialiseur, le menu d'ornement contexte,, adaptateurs, etc
3. L'intégration Boîte à outils, comme des icônes, l'enregistrement de contrôle
4. IntelliSense pour l'éditeur de code

Sauf intellisense (veuillez voir Ajouter Intellisense riches pour vos contrôles Silverlight ) et le contrôle d'enregistrement (s'il vous plaît voir enregistrer les contrôles Silverlight avec Visual Studio et Blend ), ci-dessus l'expérience le temps de conception sont généralement livrés à travers des assemblées de temps de conception. Ci-dessous je vais discuter de diverses approches de fournir des expériences de temps de conception, de la complexité croissante et la flexibilité, et introduire progressivement des morceaux de la convention de nommage pour les assemblages de temps de conception.

Assemblée Runtime seulement

Le plus simple pour offrir une expérience de la conception consiste à emballer le code moment de la conception dans les assemblées d'exécution, en particulier lorsque les métadonnées moment de la conception sont significatifs lors de l'exécution aussi, comme TypeConverterAttribute .

Les avantages et les inconvénients de cette approche:

• Pro: simple
  • pas d'assemblées distinctes de temps de conception, d'installation simple
  • attributs de temps de conception sont indiquées directement sur le code d'exécution, plus facile à entretenir
• Con: raccord étanche de l'exécution et le code de la conception
  • la dégradation de perf en raison de code de conception du temps inutile à l'exécution
  • dépendances de temps de conception (comme MWDs et autres VS / Blend ensembles) se laisser entraîner dans l'exécution inutilement
  • ne peut pas traiter l'exécution ou le temps de conception indépendamment
  • ne peut pas aider les concepteurs multiples (comme la fois VS2008/Blend2 et VS2010/Blend3)

Les inconvénients sont particulièrement mauvais pour Silverlight, car les assemblys au moment du design sont en réalité. NET, avec des références à des types Silverlight. Le mélange de Silverlight et. NET peut être difficile et déroutant, et peut conduire à des bugs subtils. En outre, les applications Silverlight sont la plupart du temps des applications web, donc la taille de téléchargement et la performance sont particulièrement importants. Déplacement dans. NET dans des applications Silverlight n'aide certainement pas. Donc, cette approche est fortement déconseillée, sauf s'il ya une justification solide pour cela.

Partagé Assemblée moment du design

Donc, l'étape révolutionnaire d'avancer est de découpler le temps de conception et de code d'exécution, la libération et les servir avec des assemblages distincts. Cela ouvre toutes sortes de possibilités. Bien sûr, nous devons trouver un moyen de lier assemblées temps de conception à leurs assemblées d'exécution correspondantes, sans introduire de toute dépendance inutile ou la dégradation de perf aux assemblées d'exécution. D'où la convention de nommage: si un Foo.dll assembly de runtime est référencé dans un projet Silverlight, le concepteur (comme Visual Studio et Blend) va d'abord essayer de charger les informations de la conception comme des icônes (par l'intermédiaire d'une autre convention de nommage, voir Comment faire pour ajouter une boîte à outils Icône pour votre contrôle Silverlight ) et les métadonnées moment de la conception (via l'interface, comme IRegisterMetadata pour VS2008 et Blend2, ou IProvideAttributeTable pour VS2010 et Blend3 S'il vous plaît voir. Comment écrire moment du design Silverlight pour tous les concepteurs: Visual Studio 2008, Blend 2; Blend 3, et Visual Studio 2010 ) à partir de l'assembly de runtime, il cherchera alors un ensemble de temps de conception par le Foo.Design.dll nom dans le même répertoire que Foo.dll; s'il est trouvé, le concepteur va essayer de charger des informations en temps de conception de Foo . Design.dll ainsi.

Designer Assemblée spécifique moment du design

Visual Studio est la plupart du temps pour les développeurs, tout en Blend est surtout pour les concepteurs, de sorte qu'ils ont des exigences différentes pour des expériences de temps de conception. Mettre tout le code moment du design dans un ensemble de conception à temps partagé introduit raccord étanche entre les concepteurs. Ainsi, la convention de nommage est renforcée: pour Foo.dll assembly de runtime, il ya une conception partagée Foo.Design.dll temps de montage qui est chargé par tous les concepteurs; chaque concepteur tentera également de charger ses propres assemblées temps de conception, comme Foo.VisualStudio. Design.dll pour Visual Studio, et Foo.Expression.Design.dll Blend. Le concepteur de montage spécifique le temps de conception est chargé après l'assemblée le temps de conception partagée. Concepteurs tiers peuvent définir leur propre concepteur spécifique de montage de la conception. Silverlight Toolkit Décembre 2008 Communiqué utilise cette convention de nommage. S'il vous plaît voir Caractéristiques moment du design dans Silverlight Toolkit et de mise en œuvre d'entité au moment du design dans Silverlight Toolkit pour plus d'informations.

Dossier de conception Sous

Donc, pour soutenir à la fois Visual Studio et Blend, chaque ensemble d'exécution dispose de trois ensembles de temps de conception, dans le même répertoire, et un paquet (comme Silverlight SDK ou Silverlight Toolkit ) contient généralement plusieurs ensembles d'exécution. Ainsi, le répertoire est un peu encombré. Une légère amélioration est de mettre les assemblées au moment du design dans un sous-dossier de conception. Ainsi, la convention de nommage est encore renforcée: si un designer (comme Visual Studio ou Blend) ne peut pas trouver correspondantes assemblées moment du design dans le même répertoire que un assembly de runtime, il les chercher dans le sous-dossier de conception, si elle existe.

En charge plusieurs versions de MWDs

Temps de conception sont construits au-dessus de l'extensibilité du concepteur cadre , qui se compose de plusieurs DLL comme Microsoft.Windows.Design.Extensibility.dll et Microsoft.Windows.Design.Interaction.dll. Nous avons l'habitude de les appeler collectivement MWDs. Pour rendre la vie plus intéressante, nous avons parfois à introduire des modifications avec rupture à l'infrastructure d'extensibilité, comme VS2008 et Blend2 utilisation MWD version 3.5, VS2010 et Blend3 utilisation la version MWD 4.0, et ils sont incompatibles. Donc, si vous avez un Foo.dll assembly de runtime, et vous voulez que vos utilisateurs soient en mesure de développer des contre elle à la fois avec VS2008 et VS2010, vous devez fournir deux ensembles d'assemblages de temps de conception: un jeu construit contre v3.5 MWDs et utilisé par VS2008, et un autre ensemble construit contre v4.0 MWD et utilisé par VS2010. Les deux ensembles d'assemblages de temps de conception sans doute beaucoup de code en commun, tandis que celui pour VS2010 peut avoir un nouveau code de tirer parti des nouvelles fonctionnalités exposées par VS2010. Depuis assemblées temps de conception sont chargés par leur nom et vous ne pouvez pas avoir deux fichiers portant le même nom, de sorte que la convention de nommage est renforcée encore:

pour un assembly de runtime Foo.dll, l'assemblage de conception partagée du temps est nommé * Foo.Design. dll, le Visual Studio spécifique ensemble le temps de conception est nommé * Foo.VisualStudio.Design. dll, et le mélange de montage spécifique le temps de conception est nommé Foo . Expression.Design *. dll, où * peut être zéro ou plusieurs caractères valides pour les noms de fichiers. Quand un designer (comme Visual Studio ou Blend) tente de charger un assembly moment de la conception et l'ajustement de plusieurs conventions de nommage, zéro ou un sera chargé:

• Si la version MWD référencé par l'assemblée au moment du design a un numéro de version majeure différente que la version MWD du concepteur, puis l'ensemble au moment du design ne se charge pas et est court-circuité.
• Si plus d'un dessin-temps de montage est compatible avec la version MWD du concepteur, le concepteur de la charge compilé contre la version la plus récente MWD qui est inférieure ou égale à la version MWD du concepteur.

Silverlight 3 Toolkit Octobre 2009 Communiqué utilise cette convention de nommage pour soutenir à la fois VS2008 et Blend3/VS2010. S'il vous plaît voir le temps de conception Silverlight: Boîte à outils mise à jour Octobre 2009 Communiqué , Comment écrire le temps de conception Silverlight pour tous les concepteurs: Visual Studio 2008, Blend 2; Blend 3, et Visual Studio 2010 , et la série d'extensibilité - Partage WPF et Silverlight code au moment du design - Partie I de plus amples renseignements.

Soutient à la fois WPF et Silverlight

Pour compliquer la vie plus loin, car WPF et Silverlight sont si terriblement similaire, vous pourriez être tenté d'essayer de l'écrire une fois et exécuter à la fois WPF et Silverlight. Vous n'êtes pas seul. Il ya de nombreux articles sur la façon de partager le code source et / ou binaires dans Silverlight et WPF. Nous aimerions le faire pour les assemblages de temps de conception trop, c'est à dire avoir les mêmes ensembles de temps de conception pour WPF et Silverlight contrôles. Une approche consiste à faire la plupart du temps la conception agnostique assemblées plate-forme, et la plate-forme de limite spécifique (WPF ou Silverlight) du code et les références à un ensemble de petite plate-forme spécifique. Silverlight 3 SDK RDA 2 (installé par VS2010 automatiquement aussi) utilise cette approche pour DataGrid créateur (il ya un System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll dans le répertoire SDK). S'il vous plaît voir la série d'extensibilité - Partage WPF et Silverlight code au moment du design - Partie I pour plus d'informations.

Victoires One Last

Les métadonnées de conception même temps pour une classe ou son membre peut être spécifiée plusieurs fois dans plusieurs ensembles de temps de conception, ce qui permet l'assemblage de conception partagée de temps pour préciser default / comportement commun, puis designer spécifiques assemblées temps de conception pour remplacer si nécessaire. Les métadonnées de conception même temps peut également être spécifiée plusieurs fois dans un temps de montage de conception unique (veuillez voir la mise en œuvre d'entité au moment du design dans Silverlight Toolkit comme un exemple, où DescriptionAttribute pour une classe ou à ses biens peuvent être ajoutés par AddDescriptions, les AddAttributes et méthodes AddTables) . Nous avons donc besoin de savoir qui gagne des métadonnées. La conception simple et la plus logique est l'un gagne dernières. Cela est surtout vrai, mais pas toujours. Parfois, le résultat peut être non-déterministe lorsque les métadonnées de conception même temps est spécifié plusieurs fois, mais avec des valeurs différentes.

Réaction

Temps de conception peut sembler facile, mais du diable est dans les détails! Feedbacks sont toujours appréciés. S'il vous plaît laissez-moi savoir ce que vous avez des questions sur, ce que les demandes ou les améliorations que vous aimeriez faire, pour la conception fois l'expérience et d'extensibilité du concepteur. Merci!