Ning Zhang blog

Présentation

Si vous écrivez contrôles Silverlight, vous devriez envisager d'écrire assemblées temps de conception pour vos contrôles aussi, pour deux raisons simples:

• la productivité du développeur: essayez d'imaginer le développement de Silverlight sans outils comme Visual Studio ou Blend! Pour les contrôles personnalisés, vous pouvez avoir besoin de fournir beaucoup plus de l'expérience de temps de conception pour vos contrôles dans Visual Studio ou vous Blend.
• concepteurs: XAML et des outils comme Mélange de permettre aux développeurs et aux concepteurs de travailler ensemble. Un des critères de conception clés pour les contrôles Silverlight est de faire 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 pas exclusivement) les suivantes:

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

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

Assemblée exécution uniquement

La façon la plus simple pour offrir une expérience de temps de conception consiste à emballer le code temporel de conception dans les assemblées d'exécution, surtout lorsque le temps de conception de métadonnées sont utiles à l'exécution aussi, comme TypeConverterAttribute .

Les avantages et les inconvénients de cette approche:

• Pro: simple
  • pas d'assemblées séparées de la conception, l'installation plus simple
  • attributs de temps de conception sont spécifiées directement sur le code d'exécution, plus facile à entretenir
• Con: couplage serré de l'exécution et le code de temps de conception
  • dégradation de perf en raison des codes de conception du temps inutiles à l'exécution
  • dépendances temps de conception (comme MWDs et autres VS / Mélange assemblées) se laisser entraîner dans l'exécution inutilement
  • ne peut pas de service d'exécution ou le temps de conception indépendante
  • ne peut pas soutenir les concepteurs multiples (comme tant VS2008/Blend2 et VS2010/Blend3)

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

Partagé Assemblée moment du design

Donc l'étape révolutionnaire est heureux de découpler le temps de conception et d'exécution de code, la libération et de services entre eux avec des assemblées séparées. Cela ouvre toutes sortes de possibilités. Bien sûr, nous avons besoin d'un moyen de lier les assemblées temps de conception à leurs assemblées d'exécution correspondant, sans introduire de toute dépendance inutile ou la dégradation de perf aux assemblées de l'exécution. D'où la convention de nommage: si un Foo.dll Assemblée exécution est référencée dans un projet Silverlight, le concepteur (comme Visual Studio et Blend) va d'abord essayer de charger des informations en temps de conception comme des icônes (via une autre convention de nommage, voir Comment ajouter une boîte à outils Icône pour votre contrôle Silverlight ) et le temps de conception des métadonnées (via l'interface, comme IRegisterMetadata pour VS2008 et Blend2 ou IProvideAttributeTable pour VS2010 et Blend3 S'il vous plaît voir. Comment écrire le temps de conception de Silverlight pour tous les concepteurs: Visual Studio 2008, Blend 2, Blend 3, et Visual Studio 2010 ) de l'Assemblée d'exécution, il cherchera alors un assemblage de temps de conception par la 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.

Concepteur Assemblée spécifiques moment du design

Visual Studio est surtout pour les développeurs, tout mélange est surtout pour les concepteurs, ils ont des exigences différentes pour des expériences de temps de conception. Mettre tout le code moment du design dans la conception d'une assemblée temps partagé introduit serrés couplage entre les concepteurs. Ainsi, la convention de nommage est renforcée: pour l'assemblage Foo.dll exécution, 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écifiques du 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écifiques Assemblée temps de 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 de conception Feature temps dans Silverlight Toolkit pour plus d'informations.

Conception sous-dossier

Donc, pour soutenir à la fois Visual Studio et Blend, chaque assemblage d'exécution a trois assemblées de la 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 serré. Une amélioration mineure est de mettre les assemblées temps de conception dans un sous-dossier de conception. Ainsi, la convention de nommage est encore renforcée: si un concepteur (comme Visual Studio ou Blend) ne peut pas trouver correspondante assemblées moment du design dans le même répertoire que l'exécution d'une assemblée, il va chercher pour eux dans le sous-dossier de conception, si elle existe.

Soutien de plusieurs versions d'MWDs

Le temps de conception sont construits sur le dessus de cadre de l'extensibilité du concepteur , qui se compose de plusieurs DLL comme Microsoft.Windows.Design.Extensibility.dll et Microsoft.Windows.Design.Interaction.dll. En général, nous les appelons collectivement MWDs. Pour rendre la vie plus intéressante, nous avons parfois à introduire des modifications à briser le cadre d'extension, comme VS2008 et de l'utilisation Blend2 MWD version 3.5, VS2010 et de l'utilisation Blend3 MWD version 4.0, et ils sont incompatibles. Donc, si vous avez un Foo.dll Assemblée exécution, et vous voulez que vos utilisateurs d'être en mesure de développer son encontre à la fois avec VS2008 et VS2010, vous devez fournir deux ensembles d'assemblages temps de conception: un ensemble construit contre v3.5 MWDs et utilisé par VS2008, et un autre ensemble construit contre v4.0 MWD et utilisés par VS2010. Les deux ensembles d'assemblages temps de conception ont probablement beaucoup de code en commun, tandis que l'autre 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 avec le même nom, donc la convention de nommage est renforcée encore:

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

• Si la version MWD référencés par l'assembly moment de la conception a un numéro de version majeure différente que la version MWD du concepteur, puis l'assemblage de conception ne se charge pas et est contourné.
• Si plus d'un dessin-temps de montage est compatible avec la version MWD le concepteur, le concepteur charge la compilé avec la plus haute version MWD qui est inférieur ou égal à la version MWD du concepteur.

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

Soutien à la fois WPF et Silverlight

Pour compliquer la vie encore, car WPF et Silverlight sont si terriblement semblables, vous pouvez être tenté d'essayer de l'écrire une fois et courir avec 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 faire cela pour des assemblages de temps de conception trop, c'est à dire avoir le même temps les assemblées de conception pour WPF et Silverlight contrôle. Une approche consiste à faire la plupart du temps la conception agnostique assemblées plate-forme et plate-forme de limite spécifique (WPF ou Silverlight) du code et les références à un assemblage 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 l'extensibilité de la série - Partage de code WPF et Silverlight au moment du design - Partie I pour plus d'informations.

Un dernier gagne

Les métadonnées de conception même temps pour une classe ou un de ses membres peut être spécifiée plusieurs fois dans de multiples assemblées temps de conception, qui permet l'assemblage de conception partagée de temps pour préciser default / comportement commun et designer en particulier les assemblées de la conception pour remplacer si nécessaire. Les métadonnées de conception même temps peut également être spécifié plusieurs fois dans une assemblée le temps de conception unique (s'il vous plaît voir la mise en œuvre Feature Time Design dans Silverlight Toolkit comme un exemple, où DescriptionAttribute pour une classe ou ses biens peuvent être ajoutés par AddDescriptions, AddAttributes et méthodes AddTables) . Nous avons donc besoin de savoir quelles métadonnées gagne. La conception simple et la plus logique est le dernier gagne. 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.

Commentaires

Le temps de conception peut sembler facile, mais diable est dans les détails! Feedbacks sont toujours appréciés. S'il vous plaît laissez-moi savoir ce que vous rencontrez des problèmes, ce que les demandes / améliorations que vous aimeriez faire, pour la conception de deux fois l'expérience et le cadre de l'extensibilité du concepteur. Merci!