Unni's Blog : Extensibility

AlternateContentProperty attribute

unnir — Sat, 28 Mar 2009 23:42:00 GMT

A new extension point we have added to Blend 3 (based on very popular demand) can be seen put to good use with the Silverlight Chart control - we call it the AlternateContentProperty attribute. Annotating the properties of a control with this attribute allows you to select objects that are set as values (including DepedencyObjects) to be selected in the Blend object tree, thereby exposing a ton of new functionality like the ability to set properties on those objects, edit templates if those objects were FrameworkElements, or set new objects as values of these properties.

Kudos to the Silverlight toolkit team for jumping onto this (I hope a lot more people notice and use this feature in Blend 3 as it really, really enables designers).

A sample that shows the new Blend design surface extensibility

unnir — Fri, 27 Mar 2009 23:39:00 GMT

Based on popular demand, here is a quick sample (WPF only though it would be very easy to port this as-is to Silverlight - currently busy with Blend 3 work and all the cool newer features we are adding to Blend 3) that will allow you to get started on the following new extension points we have added to Blend 3:
a) The new way to specifying metadata for your controls
b) DefaultInitializer that allows you to set properties when a control in instantiated from the Blend asset library
c) Custom context menus
d) An adorner for the control

Let me know if you wanted some samples for any specific scenarios you might be interested in.

Writing a design time experience for a Silverlight control

unnir — Mon, 23 Mar 2009 01:31:00 GMT

Writing a design time experience for a Silverlight control can be a bit intimidating (the experience for WPF controls remains unchanged from Blend 2 - just that you now have a ton more extensibility points - unless you wanted to re-use the same design-time code for the WPF and Silverlight versions of your controls). Let's try and understand how this works (because once you know the basics, its a breeze!).

Here is a project template that will help you get started immediately. All you need to do to use this project template is to unzip the contents to a folder like C:\Users\<username>\Documents\Expression\Blend 3\ProjectTemplates. Also, sorry - I did not have time to create a VB version yet.

The project created from this project template works as follows:

Two control libraries are created each time you create and instance of the project template. For example, lets assume the the user chose the name "MySilverlightControl" as the name for the control library. The two libraries that are created are called MySilverlightControl.dll, and MySilverlightControl.Design.dll.
The output path of MySilverlightControl.Design.csproj is set to copoy the library alongside MySilverlightControl.dll in a sub-folder called Design. This is identical to what you would do for a WPF control library - adding the design time library to a sub-folder prevents pollution of the "Add Reference" dialogs in the tools.
MySilverlightControl.Design.csproj is basically a WPF control library project (all the user interface components for the design time experience and metadata that you will specify for the controls are using the desktop CLR/WPF), and has the following:

A project-to-project reference to MySilverlightControl.csproj
Because MySilverlightControl.csproj is a Silverlight project (and because we want to use Silverlight types when we code the design time experience - more on this shortly), we need to add a reference to the Silverlight System.Windows.dll
References to the two Blend 3 / VS Next shared extensbility libraries - Microsoft.Windows.Design.Interaction.dll, and Microsoft.Windows.Design.Extensibility.dll. (Note: In Blend 2/VS 2008, we also had Microsoft.Windows.Design.dll - the APIs in this dll have been moved into the other two libraries, and MWD.dll is no more)
Because you have references to PresentationFramework.dll and System.Windows.dll, there is a conflict of types when you use a type like Button which exists in both. To help reslove this conflict for the compiler, we setup an alias for the Silverlight System.Windows.dll - TargetPlatform. Any type that is referenced using TargetPlatform::X.Y.Z is now resolved against the Silverlight assembly.

For both WPF and Silverlight control libraries, while the way you specify the metadata tables is still compatible with VS 2008 / Blend 2, the registration mechanism has a breaking change. You now need to use an assembly level attribute - ProvideMetadata - for this. You can find an example for this in MetadataStore.cs in the MySilverlightControl.Design.csproj.

While there are clear benefits to the approach we have chosen to support both WPF and Silverlight controls (same extensibility APIs so you don't have to learn two sets of APIs, ability to reuse the code for your design time experiences for WPF and Silverlight version of your controls by simply creating platform specific versions of the design time libraries), there are some pitfalls for advanced scenarios that can be easily avoided:

There are breaking changes to the APIs. Because Visual Studio 2008 SP1 GACs assemblies, unless you had a strong reference to the new assemblies, you might get compiler errors if the assemblies don't resolve to the new versions. Another option is to copy the assemblies locally into the project, and reference them from there. This issue will be addressed in a more convenient fashion shortly.
It is very easy to to unknowingly pass in a platform specific object (say System.Windows.Point) into an API (for example, the ModelItem ones to set values) where the platform is not compatible. This can be easily avoided by using aliasing appropriately.
The .Net 3.5 SP1 WPF markup compiler (which comes into play when you try to define WPF UI for your desing-time - for example, a custom category layout for the property inspector or an adorner) does not play well with the aliasing system. To avoid this, consider separating the UI for the design time into a separate project that is a WPF only and has no references to the Silverlight assemblies.

Enjoy, and please do let me know if you run into issues as you work with Silverlight design time experiences so we can address them.

Blend 3 Extensibility

unnir — Wed, 18 Mar 2009 03:27:00 GMT

Based on popular customer feedback, we have added a number of new extensibility points in Blend 3 (sorry, no support for plugins, yet, but who needs an officially supported extensibility model anyway? :) )

Over the next few weeks, I will provide more information on these, including interesting use cases that are already starting to pop up. Here is a quick listing of what we currently support:

Project and item templates: We support the same formats as Visual Studio, with some very minor modifications to suite our user experience. User project and item templates can be copied into C:\users\username\Documents\Expression\Blend 3\ProjectTemplates and \ItemTemplates respectively. We do not support wizards yet.
The Blend Asset Library

Ability to register your custom controls. For example, to register a control library Foo.dll, all you need to do is to add the path to the control library as a value of the following registry key - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Expression\Blend\v3.0\Toolbox\Silverlight\v3.0\MyCustomControlLibraryKey. If this were a WPF library, the key you would setup is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Expression\Blend\v3.0\Toolbox\WPF\v3.5\MyCustomControlLibraryKey
Adding an asset adds necessary assemblies to your project
Support for custom control icons
Setting custom properties on your control when they get instantiated - DefaultInitializer.

Design surface for custom controls

Custom context menu commands
Adorners
Selection/object manipulation APIs

Property grid extensibliity - same support as Blend 2, with a few minor additions here and there

Some other notes:
Blend 3 will share the same extensibility model as the next version of Visual Studio.

As we live in a world where there is greater and greater parity between WPF and Silverlight, we wanted the same for these APIs wherein you could use the same design time code to target controls for both platforms. To accomodate this, we had to make some minor breaking changes to the VS 2008 APIs (hopefully the changes will be very straightforward to adapt to) - I will try to post a number of samples to help out with this. By and large, the APIs remain the same as documented here (the documentation will be updated to reflect the breaking changes at a later date).

The APIs are not final yet, and are subject to change. Hopefully, we can keep the changes to a minimum.