Ning Zhang Blog

Einführung

Wenn Sie Silverlight-Steuerelemente schreiben, sollten Sie schriftlich Design-Zeit-Baugruppen für die Steuerelemente auch für zwei einfache Gründe:

• Produktivität der Entwickler: versuchen Silverlight Entwicklung ohne Werkzeuge wie Visual Studio oder die Mischung vorstellen! Für benutzerdefinierte Steuerelemente, müssen Sie viel von der Design-Erfahrung für Ihre Steuerelemente bieten in Visual Studio oder die Mischung sich.
• Designer: XAML und Tools wie Blend-ermöglichen Entwicklern und Designern zusammenarbeiten. Eine wichtige Design-Kriterien für Silverlight-Steuerelemente ist, um sicherzustellen, Designer können sie benutzen, ohne eine einzige Zeile Code.

Design-Erfahrung umfasst in der Regel (aber nicht beschränkt auf) die folgenden:

1. Metadaten für Eigenschaften-Fenster, wie Kategorie, infotip, benutzerdefinierte Eigenschaft / binding / Sammlung Editoren etc.
2. Metadaten für Design Oberfläche, wie Initialisierung, Adorner, Kontextmenü, Adapter etc.
3. Toolbox Integration, wie Ikonen, Steuer-Registrierung
4. IntelliSense für Code-Editor

Außer intellisense (siehe Add Rich-Intellisense für Ihre Silverlight-Steuerelemente ) und Kontrolle Registrierung (siehe Register Silverlight Controls mit Visual Studio und Blend ), sind über Design-Zeit Erfahrung in der Regel durch Design-Zeit Baugruppen geliefert. Im Folgenden werde ich diskutieren verschiedene Ansätze der Bereitstellung von Design-Zeit Erfahrungen, in wachsender Komplexität und Flexibilität und schrittweise einzuführen Stücke der Namenskonvention für Design-Zeit-Baugruppen.

Runtime Montage nur

Die einfachste Art, Design Erfahrung liefern wird, um Design-Zeit-Code in die Common Language Runtime-Baugruppen-Paket, vor allem, wenn Design-Zeit Metadaten sinnvoll zur Laufzeit auch, wie TypeConverterAttribute .

Die Vor-und Nachteile dieses Ansatzes:

• Pro: einfache
  • keine separate Design-Zeit-Baugruppen, einfacher Aufbau
  • Entwurfszeit-Attribute werden direkt auf die Runtime-Code angegeben, leichter zu warten
• Con: enge Kopplung von Laufzeit-und Entwurfszeit-Code
  • perf Abbau wegen nutzlos Design Time-Code zur Laufzeit
  • Design-Zeit-Abhängigkeiten (wie MWDs und anderen VS / Blend Baugruppen) gelangen in Runtime gezogen unnötig
  • kann nicht Service-Laufzeit oder Design-Zeit unabhängig
  • nicht unterstützen können mehrere Designer (wie beide VS2008/Blend2 und VS2010/Blend3)

Die Nachteile sind besonders schlecht für Silverlight, weil Design-Zeit-Baugruppen in Wirklichkeit sind. NET-Assemblies, mit Verweisen auf Silverlight-Typen. Mixing Silverlight und. NET-Assemblies kann eine Herausforderung sein und verwirrend und kann zu subtilen Fehlern führen. Auch sind Silverlight-Anwendungen vor allem Web-Anwendungen, so zum Download Größe und Leistung sind besonders wichtig. Ziehen in. NET-Assemblies in Silverlight-Anwendungen sicher nicht helfen. So dieser Ansatz wird davon abgeraten, es sei denn, es gibt starke Rechtfertigung für sie.

Gemeinsame Design Time Assembly

So der revolutionären Schritt nach vorn ist die Design-und Runtime-Code, Release-und Service sie mit separaten Baugruppen zu entkoppeln. Dies eröffnet alle Möglichkeiten. Natürlich müssen wir einen Weg, um Design-Zeit-Baugruppen an die entsprechenden Runtime-Baugruppen verknüpfen, ohne dabei unnötige Abhängigkeit oder perf Abbau zu Laufzeit Baugruppen. Daher die Namensgebung: Wenn eine Runtime-Assembly foo.dll in einer Silverlight-Projekt verwiesen wird, der Designer (wie Visual Studio und Blend) wird zunächst versuchen, Design-Zeit Informationen wie Symbole (über eine andere Namensgebung zu laden, siehe Wie man eine Toolbox hinzufügen Icon für Ihre Silverlight Control ) und Design-Zeit-Metadaten (via Schnittstelle, wie IRegisterMetadata für VS2008 und Blend2 oder IProvideAttributeTable für VS2010 und Blend3 Bitte sehen. Wie Silverlight Design Time for All Designers schreiben: Visual Studio 2008, Blend 2; Blend 3, und Visual Studio 2010 ) aus der Runtime-Assembly, es wird dann für eine Design-Zeit Montage durch den Namen Foo.Design.dll in das gleiche Verzeichnis wie foo.dll aussehen, wenn gefunden, der Designer werden versuchen, Design-Zeit Informationen von Foo Last . Design.dll auch.

Designer Specific Design Time Assembly

Visual Studio ist vor allem für Entwickler, während Blend ist vor allem für Designer, so haben sie unterschiedliche Anforderungen an Design-Zeit Erfahrungen. Putting alle Design-Time-Code in einem gemeinsamen Design-Zeit der Montage stellt eine enge Kopplung zwischen Designern. So die Namenskonvention wird erhöht: für Runtime-Assembly foo.dll, gibt es eine gemeinsame Design-Zeit Montage Foo.Design.dll, die von allen Designern geladen ist, jeder Designer wird auch versuchen, ihre eigene Design-Zeit Versammlungen zu laden, wie Foo.VisualStudio. Design.dll für Visual Studio, und Foo.Expression.Design.dll für Blend. Der Designer spezifischen Design-Zeit der Montage ist nach dem gemeinsamen Design-Zeit Assembly geladen. Third Party Entwickler können ihre eigenen Designer-spezifischen Design-Zeit der Montage zu definieren. Silverlight Toolkit Dezember 2008 Veröffentlichung ist mit dieser Namensgebung. Bitte beachten Sie Design Time Features in Silverlight Toolkit und Design Time Feature-Implementierung in Silverlight Toolkit für weitere Informationen.

Design-Sub-Ordner

So, um sowohl in Visual Studio und Blend zu unterstützen, hat jeder Runtime-Assembly drei Design-Zeit Versammlungen, in das gleiche Verzeichnis, und ein Paket (wie Silverlight SDK oder Silverlight Toolkit ) enthält in der Regel mehrere Runtime-Baugruppen. So das Verzeichnis wird ein wenig überfüllt. Eine geringfügige Verbesserung der Design-Zeit-Baugruppen unter einem Design-Unterordner gelegt. So die Namenskonvention wird weiter verbessert: Wenn ein Designer (wie Visual Studio oder Blend) nicht finden kann entsprechende Design-Zeit-Baugruppen in das gleiche Verzeichnis wie ein Runtime-Assembly, wird es für sie in der Design-Unterordner schauen, wenn es existiert.

Unterstützung mehrerer Versionen von MWDs

Design-Zeit werden auf der eingebauten Designer erweiterbares Framework , das aus mehreren dlls wie Microsoft.Windows.Design.Extensibility.dll und Microsoft.Windows.Design.Interaction.dll besteht. Normalerweise nennen wir sie gemeinsam als MWDs. Um Ihnen das Leben interessanter, manchmal müssen wir einführen aktuellen Änderungen der erweiterbares Framework, wie VS2008 und Blend2 Verwendung MWD, Version 3.5, VS2010 und Blend3 Verwendung MWD Version 4.0, und sie sind nicht kompatibel. Wenn Sie also eine Runtime-Assembly foo.dll haben und Sie möchten Ihre Benutzer in der Lage sein, gegen ihn mit beiden VS2008 und VS2010 entwickeln, müssen Sie zwei Sätze von Design-Zeit-Baugruppen bieten: einen Satz gegen v3.5 MWDs gebaut und eingesetzt von VS2008, und einen weiteren Satz gegen v4.0 MWD und von VS2010 gebaut. Die beiden Sätze von Design-Zeit-Baugruppen haben wahrscheinlich eine Menge Code gemeinsam, während die einen für VS2010 einige neue Code haben könnten zu nutzen, die neuen Funktionalitäten von VS2010 ausgesetzt. Da Entwurfszeit Baugruppen nach Name geladen werden und Sie können nicht zwei Dateien mit demselben Namen, so dass die Namensgebung noch einmal erhöht:

für eine Runtime-Assembly foo.dll, das gemeinsame Design-Zeit Assembly mit dem Namen ist Foo.Design *. dll, ist die Visual Studio spezifischen Design-Zeit Assembly mit dem Namen Foo.VisualStudio.Design *. dll, und die Mischung spezifischen Design-Zeit Baugruppe ist mit dem Namen Foo . Expression.Design *. dll, wobei * Null oder mehr gültige Zeichen für Dateinamen werden können. Wenn ein Designer (wie Visual Studio oder Blend) zu einem Design-Zeit Assembly zu laden und mehrere fit die Namensgebung versucht, wird Null oder Eins geladen werden:

• Wenn die MWD-Version von der Design-Time-Montage verwiesen hat einen anderen Major-Versionsnummer als die Designer-MWD-Version, dann ist die Design-Time-Montage wird nicht geladen und wird umgangen.
• Wenn mehr als ein Design-Time-Montage ist kompatibel mit dem Designer-MWD-Version, lädt das Designer das eine gegen das höchste MWD-Version, die weniger als oder gleich dem Designer MWD-Version kompiliert wird.

Silverlight 3 Toolkit Oktober 2009 Veröffentlichung verwendet diese Namenskonvention sowohl VS2008 und Blend3/VS2010 unterstützen. Bitte beachten Sie Silverlight Design Time: Toolkit Oktober 2009 Release Update , Wie, um Silverlight Design Time for All Designers schreiben: Visual Studio 2008, Blend 2; Blend 3 und Visual Studio 2010 und Erweiterbarkeit Series - WPF & Silverlight Design-Time Code Sharing - Part I weitere Informationen.

Unterstützt sowohl WPF und Silverlight

Noch komplizierter wird das Leben weiter, da WPF und Silverlight so schrecklich ähnlich sind, könnten Sie versucht zu versuchen, es einmal zu schreiben und laufen mit WPF und Silverlight werden. Du bist nicht allein. Es gibt viele Artikel, wie Sie Quellcode und / oder Binärdateien über Silverlight und WPF teilen. Wir möchten, dass für die Design-Zeit-Baugruppen zu tun, also die gleiche Design-Zeit-Baugruppen sowohl für WPF-und Silverlight-Steuerelemente. Ein Ansatz ist, die meisten der Design-Zeit Baugruppen plattformunabhängig zu machen, und zu begrenzen plattformspezifische (WPF oder Silverlight-Code) und Verweise auf eine kleine Plattform spezifische Montage. Silverlight 3 SDK DDR 2 (installiert von VS2010 automatisch zu) verwendet diesen Ansatz für DataGrid Designer (es gibt eine System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll im SDK-Verzeichnis). Bitte beachten Sie Erweiterbarkeit Series - WPF & Silverlight Design-Time Code-Sharing - Teil I für weitere Informationen.

Last One Wins

Das gleiche Design-Zeit die Metadaten für eine Klasse oder ihrer Mitglieder kann mehrere Male in verschiedenen Design-Zeit-Baugruppen, die das gemeinsame Design-Zeit Baugruppe default / allgemeines Verhalten und Designer spezifischen Design-Zeit Baugruppen angeben, um sie bei Bedarf überschreiben können angegeben werden. Das gleiche Design-Zeit-Metadaten können auch mehrere Male innerhalb einer einzigen Design-Zeit-Einheit (siehe angegeben werden Design-Time Feature-Implementierung in Silverlight Toolkit als ein Beispiel, wo DescriptionAttribute für eine Klasse oder ihr Eigentum durch AddDescriptions, addAttributes und AddTables Methoden können hinzugefügt werden) . Also müssen wir wissen, welche Metadaten gewinnt. Die einfachste und Logik-Design ist last one wins. Dies ist vor allem wahr, aber nicht immer. Manchmal kann das Ergebnis un-deterministisch, wenn die gleichen Design-Zeit Metadaten mehrmals angegeben ist, aber mit unterschiedlichen Werten.

Rückkopplung

Design-Zeit klingt einfach, aber Teufel steckt im Detail! Feedbacks sind immer willkommen. Bitte lassen Sie mich wissen, welche Themen Sie stoßen, welche Anforderungen / Verbesserungen, die Sie gerne machen würde, sowohl für Design-Zeiten Erfahrung und Designer erweiterbares Framework. Vielen Dank!