Ning Zhang Blog

Einführung

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

• Produktivität der Entwickler: versuchen, Silverlight-Entwicklung ohne Tools wie Visual Studio oder Mischung vorstellen! Für benutzerdefinierte Steuerelemente, müssen Sie unter Umständen viel von der Design-Zeit Erlebnis für Ihre Steuerelemente bieten in Visual Studio oder Blend sich.
• Designer: XAML und Tools wie Mischung ermöglichen Entwicklern und Designern zusammenarbeiten. Ein Schlüssel Design-Kriterien für Silverlight-Steuerelemente ist, 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 Redakteure usw.
2. Metadaten für Design-Oberfläche, wie Initialisierung, Adorner, Kontextmenü, Adapter usw.
3. Toolbox Integration, wie Ikonen, Steuer-Registrierung
4. IntelliSense für Code-Editor

Außer IntelliSense (sehen Sie bitte hinzufügen Rich-Intellisense für Ihre Silverlight-Steuerelemente ) und Kontrolle Anmeldung (bitte siehe registrieren Silverlight-Steuerelemente mit Visual Studio und Blend ), über Design-Erfahrung sind in der Regel durch Design-Zeit Baugruppen geliefert. Im Folgenden werde ich diskutieren verschiedene Ansätze der Bereitstellung von Design-Zeit Erfahrungen, in zunehmenden 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-Zeit Erfahrung zu liefern ist zu Entwurfszeit-Code in die Runtime-Assemblys zu verpacken, vor allem, wenn Design-Zeit aussagekräftige Metadaten zur Laufzeit sind auch, wie TypeConverterAttribute .

Die Vor-und Nachteile dieses Ansatzes:

• Pro: einfache
  • keine separaten Design-Zeit-Baugruppen, einfacher Aufbau
  • Entwurfszeit-Attribute werden direkt auf dem Runtime-Code angegeben, leichter zu warten
• Con: enge Kopplung von Runtime-und Design-Time-Code
  • Perf-Abbau wegen nutzlos Entwurfszeit Code zur Laufzeit
  • Design-Zeit-Abhängigkeiten (wie MWDs und anderen VS / Blend-Baugruppen) bekommen in Laufzeit geschleppt unnötig
  • nicht bedienen kann zur Laufzeit oder Design-Zeit unabhängig
  • kann keine Unterstützung für mehrere Designer (wie beide 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. Mixing und Silverlight. 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. Das Ziehen in. NET-Assemblies in Silverlight-Anwendungen sicherlich nicht helfen. Also dieser Ansatz wird davon abgeraten, es sei denn, es gibt starke Rechtfertigung für sie.

Shared Design Time Vollversammlung

Also die revolutionären Schritt nach vorn ist es, Design-und Runtime-Code, Release entkoppeln und warten sie mit getrennten Baugruppen. Das eröffnet alle Möglichkeiten. Natürlich brauchen wir einen Weg, um Design-Zeit-Baugruppen auf ihre entsprechenden Runtime-Baugruppen verknüpfen, ohne dabei unnötige Abhängigkeit oder perf Abbau zu Laufzeitassemblys. 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 Symbol für das Silverlight Control ) und Design-Zeit Metadaten (über Schnittstelle, wie IRegisterMetadata für VS2008 und Blend2 oder IProvideAttributeTable für VS2010 und Blend3 Bitte sehen. Wie Silverlight Design Time für alle Designer schreiben: Visual Studio 2008, Blend 2, Blend 3, und Visual Studio 2010 ) aus der Runtime-Assembly, es wird dann für ein Design-Zeit der 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 laden . Design.dll ebenso.

Designer Specific Design Time Vollversammlung

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 enge Kopplung unter den Designern. Also die Namenskonvention ist verbessert: für Runtime-Assembly Foo.dll, gibt es eine gemeinsame Design-Zeit Foo.Design.dll Montage, die von allen Designer geladen wird, jeder Designer werden 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 wird nach dem gemeinsamen Design-Zeit Assembly geladen. Dritter Designer können ihre eigenen Designer-spezifischen Design-Zeit der Montage zu definieren. Silverlight-Toolkit Dezember 2008 Veröffentlichung wird 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-Unterordner

Also, um sowohl Visual Studio und Blend zu unterstützen, hat jede Runtime-Assembly drei Design-Zeit Baugruppen, im gleichen Verzeichnis, und ein Paket (wie Silverlight SDK oder Silverlight-Toolkit ) enthält in der Regel mehrere Runtime-Baugruppen. So bekommt das Verzeichnis ein wenig überfüllt. Eine kleine Verbesserung ist es, die Design-Zeit-Baugruppen unter einem Design-Unterordner setzen. Also die Namenskonvention wird weiter verbessert: Wenn ein Designer (wie Visual Studio oder Blend) nicht finden kann entsprechende Design-Zeit-Baugruppen im gleichen Verzeichnis als Runtime-Assembly, wird es für sie in der Design-Unterordner aussehen, wenn es existiert.

Unterstützung mehrerer Versionen von MWDs

Design-Zeit werden oben auf gebaut Designer erweiterbares Framework , das aus mehreren DLLs wie Microsoft.Windows.Design.Extensibility.dll und Microsoft.Windows.Design.Interaction.dll besteht. Normalerweise nennen wir sie kollektiv als MWDs. Um Ihnen das Leben interessanter, manchmal müssen wir einführen wichtige Änderungen an den 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 sie sowohl mit VS2008 und VS2010 zu entwickeln, muss man zwei Gruppen von Design-Zeit-Baugruppen bieten: ein Satz gegen v3.5 MWDs gebaut und verwendet von VS2008, und ein anderer Satz gegen MWD v4.0 gebaut und wird von VS2010. Die beiden Design-Zeit-Baugruppen haben wahrscheinlich eine Menge Code gemeinsam, während die für ein paar neue VS2010-Code haben, können die Nutzung der neuen Funktionalitäten von VS2010 ausgesetzt. Seit Entwurfszeit Baugruppen nach Namen werden geladen und Sie können nicht zwei Dateien mit demselben Namen, so dass die Namenskonvention doch wieder erweitert:

für eine Runtime-Assembly Foo.dll, das gemeinsame Design-Zeit Assembly mit dem Namen wird Foo.Design *. dll, wird die Visual Studio-spezifischen Design-Zeit Assembly mit dem Namen Foo.VisualStudio.Design *. dll, und die Blend-spezifischen Design-Zeit der Montage wird mit dem Namen Foo . Expression.Design *. dll, wobei * Null oder mehr gültige Zeichen für Dateinamen sein kann. Wenn ein Designer (wie Visual Studio oder Blend), eine Design-Zeit mehrere Montage-und Passform der Namenskonvention zu laden versucht, wird Null oder Eins geladen werden:

• Wenn die MWD-Version von der Design-Time-Montage verwiesen hat einen anderen Major-Versionsnummer als der 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 der Designer MWD-Version, lädt das Designer den einen gegen den höchsten MWD-Version, die weniger als oder gleich des Designers MWD-Version ist kompiliert.

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

Unterstützt sowohl WPF und Silverlight

Um das Leben noch komplizierter, da WPF und Silverlight so schrecklich ähnlich sind, könnten Sie versucht sein, zu versuchen, es zu schreiben und einmal laufen sowohl mit WPF und Silverlight werden. Du bist nicht allein. Es gibt viele Artikel, wie man Source-Code und / oder Binärdateien über Silverlight und WPF teilen. Wir möchten zu tun, dass für die Design-Zeit zu Versammlungen, dh hätten die gleichen Design-Zeit-Baugruppen für WPF und Silverlight-Steuerelemente. Ein Ansatz ist, die meisten der Design-Zeit Baugruppen plattformunabhängig zu machen, und Plattform-spezifischen Grenzwert (WPF oder Silverlight-Code) und Verweise auf einer kleinen 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 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 auf Montage default / allgemeines Verhalten und Designer spezifischen Design-Zeit angeben, Versammlungen, um es bei Bedarf überschreiben können angegeben werden. Das gleiche Design-Zeit-Metadaten können auch mehrere Male innerhalb einer einzigen Design-Zeit der Montage (siehe bitte angeben Design Time Feature-Implementierung in Silverlight-Toolkit als ein Beispiel, wo DescriptionAttribute für eine Klasse oder deren 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 gleiche Design-Zeit-Metadaten wird mehrere Male, aber mit unterschiedlichen Werten angegeben.

Rückkopplung

Design-Zeit klingt einfach, aber Teufel steckt im Detail! Feedbacks sind immer willkommen. Bitte lassen Sie mich wissen, welche Themen Sie in laufen, was Wünsche / Verbesserungen, die Sie gerne machen, sowohl für Design-Zeiten Erfahrung und Designer-Erweiterbarkeit Rahmen würde. Vielen Dank!