Ning Zhang's Blog

Einführung

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

• Produktivität der Entwickler: Versuchen Sie, Silverlight Entwicklung ohne Werkzeuge wie Visual Studio oder Blend vorstellen! Für Custom Controls, müssen Sie möglicherweise einen Großteil der Design-Zeit Erfahrung für Ihre Steuerelemente in Visual Studio oder Blend selbst zur Verfügung stellen.
• Designer: XAML und Tools wie Blend ermöglicht Entwicklern und Designern zusammenarbeiten. Eine wichtige Design-Kriterien für Silverlight-Steuerelemente wird, um sicherzustellen, Designer können sie ohne eine einzige Zeile Code zu verwenden.

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ü, Adaptern etc.
3. Toolbox Integration, wie Icons, Steuerung Registrierung
4. IntelliSense für Code-Editor

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

Runtime Montage nur

Der einfachste Weg, um Erfahrung zu liefern Design-Zeit ist wie Package Design Time Code in das Runtime-Baugruppen, vor allem, wenn Design-Zeit sind aussagekräftige Metadaten zur Laufzeit auch TypeConverterAttribute .

Die Vor-und Nachteile dieses Ansatzes:

• Pro: einfache
  • keine separaten Design-Zeit Baugruppen, einfacher Setup
  • Entwurfszeit-Attribute werden direkt auf dem Runtime-Code angegeben, einfacher zu verwalten
• Con: enge Verzahnung von Laufzeit-und Design-Zeit-Code
  • Perf Abbau wegen nutzlos Design Time Code zur Laufzeit
  • Design-Zeit-Abhängigkeiten (wie MWDs und anderen VS / Blend Baugruppen) ins Runtime geschleppt unnötig
  • Service-Laufzeit kann nicht oder Design-Zeit unabhängig
  • nicht unterstützen können mehrere Designer (wie auch VS2008/Blend2 und VS2010/Blend3)

Die Nachteile sind besonders schlecht für Silverlight, weil Design-Zeit Baugruppen tatsächlich sind. NET-Assemblies, mit Verweisen auf Silverlight Typen. Mischen von Silverlight und. NET-Assemblies kann eine Herausforderung sein und verwirrend und kann zu subtilen Fehlern führen. Auch sind Silverlight-Anwendungen meist Web-Anwendungen, so download Größe und Leistung sind besonders wichtig. Ziehen in. NET-Assemblies in Silverlight-Anwendungen sicherlich nicht helfen. Also dieses Ansatzes wird davon abgeraten, es sei denn, es gibt starke Rechtfertigung für sie.

Shared Design Time Versammlung

Also der revolutionären Schritt nach vorn ist die Konzeption und Laufzeit-Code-, Veröffentlichungs-und Service entkoppeln sie mit getrennten Baugruppen. Das eröffnet alle Möglichkeiten. Natürlich brauchen wir einen Weg zur Design-Zeit zu Versammlungen der jeweiligen Laufzeit Baugruppen Link, ohne dabei unnötige Abhängigkeit oder perf Abbau zu Laufzeit Baugruppen. Daher die Namensgebung: Wenn eine Runtime-Assembly Foo.dll Silverlight-Projekt verwiesen wird, in einem Designer (wie Visual Studio und Blend) wird beim ersten Versuch zum Übereinkommen Last Entwurfszeit Informationen wie Ikonen (über eine andere Namensgebung, siehe Wie Toolbox hinzufügen Symbol 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 How to Write Silverlight Design-Time für alle Designer: Visual Studio 2008, Blend 2; Blend 3, und Visual Studio 2010 ) aus der Runtime-Assembly, es wird dann Foo.dll nach einem Design-Zeit Montage durch den Namen Foo.Design.dll in das gleiche Verzeichnis wie, wenn gefunden, der Designer werden versuchen, die Foo Last Design-Zeit Informationen aus . Design.dll ebenso.

Designer Specific Design Time Versammlung

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 erlebt. Putting alle Design-Time-Code in einem gemeinsamen Design-Zeit Montage stellt enge Kopplung unter den Designern. So ist die Namenskonvention erweitert: für Runtime-Assembly Foo.dll, es gibt eine gemeinsame Gestaltung der Zeit, dass Designer Montage Foo.Design.dll alle durch's geladen, jeder Designer werde auch versuchen, Foo.VisualStudio lädt die eigenen Design-Zeit Baugruppen, wie. Design.dll für Visual Studio, und Foo.Expression.Design.dll für Blend. Der Designer spezifischen Design-Zeit Assembly Assembly geladen, nachdem die gemeinsame Gestaltung der Zeit. Dritte können Designer Montage definieren ihre eigenen Designer-spezifischen Design-Zeit. Silverlight Toolkit Dezember 2008 Release ist die Nutzung dieser Namenskonvention. Bitte sehen Sie Design-Time-Features in Silverlight Toolkit und Design Time Feature-Implementierung in Silverlight Toolkit für weitere Informationen.

Design Sub Folder

Also bis zur Montage unterstützen sowohl Visual Studio und Blend, jeder Laufzeit hat 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 bekommt das Verzeichnis ein bisschen eng. Eine geringfügige Verbesserung ist die Design-Time Baugruppen unter einem Unterordner Design setzen. So ist die Namenskonvention weiter verbessert: Wenn ein Designer (wie Visual Studio oder Blend) finden keine entsprechende Design-Zeit Baugruppen in das gleiche Verzeichnis wie eine Runtime-Assembly, wird es Unterordner suchen sie im Design, wenn es vorhanden ist.

Unterstützung mehrerer Versionen von MWDs

Design der Zeit baute auf Designer-Erweiterbarkeit Rahmenbedingungen , die Microsoft.Windows.Design.Interaction.dll besteht aus mehreren DLLs und wie Microsoft.Windows.Design.Extensibility.dll. Normalerweise nennen wir sie kollektiv als MWDs. Um Ihnen das Leben interessanter, manchmal müssen wir einführen brechen Änderungen an der Erweiterbarkeit Rahmenbedingungen, wie VS2008 und Verwendung Blend2 MWD Version 3.5 und VS2010 Blend3 MWD Version 4.0 verwenden, und sie sind unvereinbar. Also, wenn Sie eine Runtime-Assembly Foo.dll, und Sie möchten Ihre Benutzer in der Lage sein, gegen ihn mit beiden VS2008 und VS2010 zu entwickeln, müssen Sie zwei Sätze von Baugruppen Design-Zeit: ein Satz gegen v3.5 MWDs gebaut und eingesetzt bieten von VS2008, und ein anderer Satz gegen v4.0 gebaut MWD und von VS2010. Die beiden Sätze von Design-Zeit Versammlungen haben wahrscheinlich eine Menge Code in gemeinsamen, während die einen für VS2010 einigen neuen Code zu nutzen, haben möglicherweise die neuen Funktionalitäten von VS2010 ausgesetzt. Seit Entwurfszeit Baugruppen sind mit dem Namen geladen und Sie können nicht zwei Dateien mit demselben Namen, so der Namenskonvention ist doch wieder erweitert:

für eine Runtime-Assembly Foo.dll, das gemeinsame Design-Zeit Assembly namens Foo.Design *. dll, die Visual Studio-spezifischen Design-Zeit Assembly namens Foo.VisualStudio.Design *. dll und die Blend spezifischen Design-Zeit Assembly namens Foo . Expression.Design *. dll, wo * kann null oder mehr gültige Zeichen für Dateinamen. Wenn ein Designer (wie Visual Studio oder Blend) versucht zu laden Laden einer Assembly Design-Zeit und mehrere passen die Namenskonvention, null oder werden eins:

• Wenn die Assembly verwiesen MWD Version von der Design-Zeit hat eine andere wichtige Versionsnummer als die Designer-MWD-Version, dann ist das Design-time Assembly wird nicht geladen und umgangen wird.
• Wenn mehr als ein Design-Time-Montage ist kompatibel mit dem Designer's MWD-Version, die Designer lädt die eine Version kompiliert gegen die höchsten MWD Version MWD das ist weniger als oder gleich dem Designer.

Silverlight 3 Toolkit Oktober 2009 Release verwendet diese Namenskonvention Blend3/VS2010 unterstützen sowohl VS2008 und. Bitte sehen Sie Silverlight Design Time: Toolkit Oktober 2009 Release Update , Wie Designer Alle to Write Time for Silverlight Design: Visual Studio 2008, Blend 2; Blend 3 und Visual Studio 2010 und Erweiterbarkeit Serie - WPF & Silverlight Design-Time-Code-Sharing - Teil I mehr Informationen.

Beide Support WPF und Silverlight

Noch komplizierter wird das Leben weiter, da WPF und Silverlight sind so schrecklich ähnlich sind, könnten Sie versucht, zu versuchen, es einmal zu schreiben und laufen sowohl mit WPF und Silverlight werden. Du bist nicht allein. Es gibt viele Artikel, wie Quellcode und share / oder Binärdateien über Silverlight und WPF. Wir möchten, dass zur Design-Zeit zu tun, Baugruppen, dh sie haben das gleiche Design der Zeit für beide Baugruppen WPF-und Silverlight-Steuerelemente. Ein Ansatz ist, Agnostiker einen Großteil der Design-Zeit Baugruppen Plattform und Plattform-spezifische Grenze (WPF oder Silverlight-Code) und Verweise auf eine kleine Plattform spezifische Montage. Silverlight 3 SDK DDR 2 (auch von VS2010 installiert automatisch) verwendet diesen Ansatz für DataGrid Designer (es gibt eine System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll in der SDK-Verzeichnis). Bitte sehen Sie Erweiterbarkeit Serie - WPF & Silverlight Design-Time-Code-Sharing - Teil I für weitere Informationen.

Last One Wins

Das gleiche Design-Zeit Metadaten für eine Klasse oder ihrer Mitglied kann mehrere Male in verschiedenen Design-Zeit Versammlungen, das gemeinsame Design-Zeit Assembly default / allgemeines Verhalten und dann Designer spezifischen Design-Zeit Baugruppen zu überschreiben, wenn nötig angeben können, angegeben werden. Das gleiche Design-Zeit kann auch Metadaten Montagezeit mehrfach angegeben werden, innerhalb eines einzigen Designs (siehe Design Time Feature-Implementierung in Silverlight Toolkit als ein Beispiel, wo DescriptionAttribute für eine Klasse oder sein Eigentum durch AddDescriptions hinzugefügt werden können, AddAttributes AddTables und Methoden) . Also müssen wir wissen, welche Metadaten gewinnt. Die einfachste und Logik-Design ist letzte gewinnt. Dies ist vor allem, aber nicht immer wahr. Manchmal kann das Ergebnis un-deterministisch, wenn die gleichen Design-Zeit Metadaten ist mehrfach angegeben, aber mit unterschiedlichen Werten.

Rückkopplung

Design Mal klingt einfach, aber Teufel steckt im Detail! Feedbacks sind immer willkommen. Bitte lassen Sie mich wissen, welche Themen Sie in den RUN, welche Anforderungen / Verbesserungen, die Sie gerne machen, sowohl für Design-Zeit zu erleben und Designer-Erweiterbarkeit Rahmen. Vielen Dank!