Zhang Ning blog

Introduction

Si vous écrivez des contrôles Silverlight, vous devriez considérer l'écriture de conception assemblées temps pour vos contrôles aussi, pour deux raisons simples:

• la productivité du développeur: essayez d'imaginer le développement Silverlight sans outils comme Visual Studio ou dans le mélange! Pour les contrôles personnalisés, vous pouvez avoir besoin de fournir une grande partie de l'expérience de la conception de vos contrôles dans Visual Studio ou vous Blend.
• designers: XAML et des outils comme Blend permet aux développeurs et aux concepteurs de travailler ensemble. Un 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 pas exclusivement) le texte suivant:

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

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

Durée de l'Assemblée seulement

Le plus simple pour offrir une expérience de la conception est de paquet avec le code de la conception dans les assemblées de l'exécution, en particulier lorsque les métadonnées de la conception à l'exécution sont significatives aussi, comme TypeConverterAttribute .

Les avantages et les inconvénients de cette approche:

• Pro: simple
  • pas d'assemblées distinctes moment du design, simple d'installation
  • attributs de la conception sont précisés directement sur le code d'exécution, plus facile à entretenir
• Con: couplage serré de l'exécution et le code de la conception
  • la dégradation de perf en raison du code de conception du temps inutile à l'exécution
  • dépendances moment de la conception (comme MWDs et d'autres VS / ensembles Blend) se laisser entraîner dans l'exécution inutilement
  • ne peut pas service d'exécution ou de la conception du temps de façon indépendante
  • ne peut pas soutenir les concepteurs multiples (comme les deux VS2008/Blend2 et VS2010/Blend3)

Les inconvénients sont particulièrement mauvais pour Silverlight, parce que les assemblées de la conception sont en réalité. NET assemblées, avec des références aux types Silverlight. Mélange Silverlight et. NET peut être difficile et déroutant, et peut conduire à des bugs subtils. En outre, les applications Silverlight sont pour la plupart des applications web, téléchargez donc la taille et les performances sont particulièrement importantes. Glisser dans. NET dans des applications Silverlight n'aide certainement pas. Ainsi, cette approche est fortement déconseillé, sauf s'il existe une justification solide pour cela.

Shared Time Design Assemblée

Ainsi, l'avancée révolutionnaire est de découpler les temps de conception et d'exécution du code, les sorties et les services avec des ensembles distincts. Cela ouvre toutes sortes de possibilités. Bien sûr, nous avons besoin d'un moyen de lier les assemblées moment de la conception de leurs assemblées exécution correspondante, sans introduire de toute dépendance inutile ou la dégradation des perf aux assemblées de l'exécution. D'où la convention de nommage: si un ensemble d'exécution Foo.dll 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 (via une autre convention de nommage, consultez Comment faire pour ajouter une boîte à outils icône de votre Silverlight Control ) et les métadonnées 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 Silverlight moment du design pour tous les concepteurs: Visual Studio 2008, 2 Blend; Blend 3, et Visual Studio 2010 ) de l'Assemblée d'exécution, il cherchera alors à une assemblée de la conception par le Foo.Design.dll nom dans le même répertoire que Foo.dll; s'il est détecté, le concepteur va essayer de charger les informations de temps de conception de Foo . Design.dll ainsi.

Assemblée Designer moment du design spécifique

Visual Studio est principalement pour les développeurs, tout en Blend est surtout pour les concepteurs, ils ont des exigences différentes pour des expériences de la conception. Mettre tout le code de la conception dans un assemblage de conception en temps partagé introduit couplage étroit entre les concepteurs. Ainsi, la convention de nommage est renforcée: pour l'assemblage d'exécution Foo.dll, il ya une conception partagée le temps d'assemblage Foo.Design.dll qui est chargé par tous les concepteurs, chaque concepteur allons également essayer de charger ses propres assemblées moment de la conception, comme Foo.VisualStudio. Design.dll pour Visual Studio, et Foo.Expression.Design.dll pour Blend. Le designer de l'Assemblée de temps spécifique est chargé après l'Assemblée de la conception partagée. Troisième partie concepteurs peuvent définir leur propre concepteur spécifiques Assemblée moment du design. Silverlight Toolkit Décembre 2008 Release utilise cette convention de nommage. S'il vous plaît voir Design intègre Time dans Silverlight Toolkit et le temps de conception d'entité de mise en œuvre dans Silverlight Toolkit pour plus d'informations.

Sous Design dossier

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

Versions multiples de soutien de MWDs

temps de conception sont construits au-dessus de l'extensibilité cadre designer , qui se compose de plusieurs DLL comme Microsoft.Windows.Design.Extensibility.dll et Microsoft.Windows.Design.Interaction.dll. En général, nous appelons collectivement MWDs. Pour rendre la vie plus intéressante, nous avons parfois à introduire des modifications à briser le cadre d'extensibilité, comme VS2008 et l'utilisation Blend2 MWD version 3.5, VS2010 et l'utilisation Blend3 MWD version 4.0, et ils sont incompatibles. Donc si vous avez un ensemble d'exécution Foo.dll, et vous voulez que vos utilisateurs soient en mesure de mettre au point contre elle avec tant VS2008 et VS2010, vous devez fournir deux séries d'assemblées moment de la conception: un ensemble construit contre v3.5 MWDs et utilisés par VS2008, et un autre construit contre v4.0 MWD et utilisés par VS2010. Les deux séries d'assemblées moment de la conception sans doute beaucoup de code en commun, tandis que celle pour VS2010 peut avoir un nouveau code de tirer parti des nouvelles fonctionnalités exposées par VS2010. Depuis assemblées moment de la 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 une fois:

pour une assemblée d'exécution Foo.dll, le temps de conception assembly partagé est nommé Foo.Design *. dll, le Visual Studio de conception Assemblée moment est nommé Foo.VisualStudio.Design *. dll, et le mélange de conception de montage de temps spécifique est appelé 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 un mélange) tente de charger un ensemble de conception et l'aménagement du temps de plusieurs la convention de nommage, zéro ou un sera chargé:

• Si la version MWD référencés par les temps de montage de conception a un numéro de version majeure différente de celle de MWD version concepteur, le temps de montage design ne se charge pas et est ignorée.
• Si la conception d'un temps de montage est compatible avec plus de MWD version concepteur, les charges Designer celui compilé avec la version la plus MWD qui est inférieure ou égale à la version MWD concepteur.

Silverlight 3 Octobre 2009 Communiqué Toolkit utilise cette convention de nommage pour soutenir les VS2008 et Blend3/VS2010. S'il vous plaît voir Time Design Silverlight: Octobre Toolkit sortie Update 2009 , Comment écrire Time Design Silverlight pour tous les concepteurs: Visual Studio 2008, Blend 2, Blend 3 et Visual Studio 2010 , et la série d'extensibilité - WPF &-Time Code partage Design Silverlight - Partie I de plus amples renseignements.

Support deux WPF et Silverlight

Pour compliquer la vie plus loin, car WPF et Silverlight sont si terriblement semblables, vous pouvez être tenté d'essayer de l'écrire une fois et exécuter à la fois 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 fichiers binaires dans Silverlight et WPF. Nous aimerions faire des assemblages moment de la conception trop, c'est à dire les assemblées ont même moment de la conception à la fois pour WPF et Silverlight contrôles. Une approche consiste à tirer le meilleur parti de la plate-forme de conception du temps assemblées agnostique, et la plate-forme spécifique limite (WPF ou Silverlight) code et les références à une plateforme spécifique petite assemblée. 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 extensibilité Series - WPF & Silverlight Design-Time Code partage - Partie I pour plus d'informations.

Dernière gagne

Les métadonnées de conception même temps pour une classe ou de ses membres peut être spécifié plusieurs fois dans plusieurs ensembles moment de la conception, qui permet à l'Assemblée de conception partagée de temps pour préciser default / comportement commun et designer d'assemblages de temps de conception pour le remplacer si nécessaire. Le moment de la conception même de métadonnées peuvent aussi être spécifiées plusieurs fois dans une assemblée de la conception unique (s'il vous plaît voir le temps de conception d'entité de mise en œuvre dans Silverlight Toolkit à titre d'exemple, le cas DescriptionAttribute pour une classe ou à ses biens peuvent être ajoutées par AddDescriptions, AddAttributes et méthodes AddTables) . Nous avons donc besoin de savoir qui gagne de métadonnées. Le design et la plus logique est une durée d'un simple gagne. Cela est surtout vrai, mais pas toujours. Parfois, le résultat peut être non-déterministe lorsque les métadonnées de même conception du temps est précisé à plusieurs reprises, mais avec des valeurs différentes.

Réaction

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