Ning Zhang's Blog

change history:

• 4/30/2009: published for Visual Studio 2008 SP1, Blend 3 Preview, Silverlight 3 Beta 1, and Silverlight 3 Toolkit March 2009 Release.
• 11/29/2009: updated for Visual Studio 2010 Beta 2.

I will keep the content up to date with latest version of Visual Studio, Blend & Silverlight.

Introduction

This is part of the series on design time implementation changes in Silverlight Toolkit March 2009 Release. This post illustrates the integration of Silverlight Toolkit with Visual Studio and Blend 3 after running Silverlight 3 Toolkit March 2009 Installer, and explains how it is done, so you can register your Silverlight controls with Visual Studio and Blend too.

Blend Integration

After installing Silverlight 3 Beta1 Tools, Blend 3 Preview, and Silverlight 3 Toolkit March 2009 (please see post Silverlight Toolkit Design Time Features: March 2009 Release Update, Silverlight 3 Development with Visual Studio 2008 and Blend 3 section for more information), create a Silverlight 3 Application from Blend 3, we can see that Silverlight Toolkit controls show up automatically in Asset Library:

User can drag and drop Toolkit controls from Asset Library to design or xaml view, and Blend will automatically add assembly reference, xmlns prefix and xaml code, very convenient:

Visual Studio Integration

Open the project in Visual Studio, we can see that Toolkit controls show up automatically in Visual Studio Toolbox, and user can drag and drop controls from Toolbox to design or xaml view as well:

Besides Toolbox, Toolkit assemblies also show up in Add Reference dialog:

and Choose Toolbox Items dialog:

Implementation

The integration with Visual Studio and Blend is done via registry. If you open “Silverlight 3 Toolkit March 2009.msi” in Orca, you can see the registration magic:

Register with Visual Studio

AssemblyFoldersEx

Registering with Visual Studio is mostly done via [HKLM|HKCU]\Software\Microsoft\Microsoft SDKs\Silverlight\v3.0\AssemblyFoldersEx. The References in Visual Studio page has very good explanation on AssemblyFoldersEx and reference resolution. It is a bit outdated, and is for .net instead of Silverlight. But it is mostly right for Silverlight too, and shows the root of the new toolbox registration mechanism with Visual Studio 2010. We’ve worked hard to rationalize the registration mechanism, consolidating and simplifying it across tools like msbuild, Visual Studio and Blend.

Take Silverlight 3 Toolkit October 2009 release as example:

c:\>reg query "HKEY_LOCAL_MACHINE\software\Microsoft\Microsoft sdks\Silverlight\v3.0\AssemblyFoldersEx\SilverlightToolkit0910" /s

HKEY_LOCAL_MACHINE\software\Microsoft\Microsoft sdks\Silverlight\v3.0\AssemblyFoldersEx\SilverlightToolkit0910
    (Default)    REG_SZ    C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\Oct09\Bin\

HKEY_LOCAL_MACHINE\software\Microsoft\Microsoft sdks\Silverlight\v3.0\AssemblyFoldersEx\SilverlightToolkit0910\Toolbox

1. AssemblyFolderBase indicates the target framework platform. Above registry path "\Software\Microsoft\Microsoft SDKs\Silverlight" indicates Silverlight SDK. Other possible values of AssemblyFolderBase:
   • "\Software\Microsoft\Microsoft SDKs\Windows"
   • "\Software\Microsoft\.NETFramework"
   • "\Software\Microsoft\.NETCompactFramework"
2. FrameworkVersion indicates the version of the target framework. “v3.0” in above example indicates this is for Silverlight 3. For Silverlight 4, use “v4.0”.
3. AssemblyFoldersSuffix describes the sub-target. “AssemblyFoldersEx” in above example tells build system how to resolve assembly references when path of the referenced assembly isn’t given. Other typical values of AssemblyFoldersSuffix:
   • “Install Path”: where Silverlight SDK is installed.
   • “ReferenceAssemblies”: where Silverlight SDK reference assemblies are installed.
4. PackageName indicates the name of the package registered, and its default value indicates where it is installed. In above example, “SilverlightToolkit0910” indicates this is Silverlight Toolkit October 2009 release, and its default value of “C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\Oct09\Bin\” indicates where it is installed. With this registration, Toolkit assemblies will show up in Add Reference dialog and Choose Toolbox Items dialog, and they can be references by other Silverlight projects without hint path.
5. Toolbox: the existence of Toolbox sub key tells Visual Studio 2010 to scan all assemblies under the install path of this package, and add all controls found to Visual Studio Toolbox, except those with ToolboxBrowsableAttribute(false) specified.

Toolbox Controls Installer (deprecated)

Jim Nakashima blogged about Toolbox Controls Installer for WPF controls in his post Have you seen the Toolbox Controls Installer? in 2007. Toolbox Controls Installer package is now part of Visual Studio 2008, but it doesn’t work for Silverlight because of a bug that is later fixed in Visual Studio 2010. Given the new AssemblyFoldersEx\Toolbox registration mechanism, there is no reason to use TCI with Visual Studio 2010 and later.

Register with Blend

Registering with Blend is via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Expression\Blend\v3.0\Toolbox\Silverlight\v3.0:

c:\>reg query "hklm\software\Microsoft\expression\blend\3.0\toolbox\Silverlight\v3.0\SilverlightToolkit0910" /s

HKEY_LOCAL_MACHINE\software\Microsoft\expression\blend\3.0\toolbox\Silverlight\v3.0\SilverlightToolkit0910
    (Default)    REG_SZ    C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\Oct09\Bin\

Unni Ravindranathan’s blog post Blend 3 Extensibility has more information about this mechanism. You can kind of mapping this registration mechanism to above Visual Studio registration mechanism:

• AssemblyFolderBase is “\Software\Microsoft\Expression\Blend\v3.0\Toolbox\Silverlight”
• FrameworkVersion is “3.0”
• PackageName is “SilverlightToolkit0910”, and its default value “C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\Oct09\Bin\” indicates where it is installed.

One caveat: if the registered assemblies depend on other assemblies, those dependent assemblies need to be in the same directory as registered assemblies, or themselves registered under AssemblyFoldersEx as described above.

Conclusion

Registration with Visual Studio and Blend makes Silverlight Toolkit controls a lot easier to use for developers. We are constantly looking at improving the registration mechanism in hope to make it simple and consistent across designers (Visual Studio and Blend) and technologies (WPF and Silverlight). All feedbacks are welcome!