Building Visual Add-Ins with WPF - New in .NET 3.5!
You’re unlikely to be reading this if you haven’t used the .NET Framework to build managed applications. As such, you’ll know how extensive the .NET Framework is in the range of support it provides for application developers.
One feature that is notable by its absence has been direct support for building applications that can host add-ins. Such applications include Visual Studio, Windows Media Player (aka plug-ins), and Internet Explorer (aka add-ons). Add-in host applications expose a range of services for add-ins via a set of interfaces that are collectively referred to as the contract. Through a contract, an add-in integrates with and extends the host application. Examples of add-ins include encoder and decoder plug-ins for Windows Media Player, the Silverlight add-on for Internet Explorer, and code line counter add-ins for Visual Studio.
The .NET Framework does of course provide basic support you need to build add-in support into your applications. Unfortunately, this support is at too low a level to enable developers to be productive, especially when considering the infrastructure that a host application needs to host add-ins typically requires the following functionality:
- Discovery: Finding add-ins that adhere to contracts supported by host applications.
- Activation: Loading, running, and establishing communication with add-ins.
- Isolation: Using either application domains or processes to establish isolation boundaries that protect applications from potential security and execution problems with add-ins.
- Communication: Allowing add-ins and host applications to communicate with each other across isolation boundaries by calling methods and passing data.
- Lifetime Management: Loading and unloading application domains and processes in a clean, predictable manner.
- Versioning: Ensuring that host applications and add-ins can still communicate when new versions of either are created.
With the .NET Framework 3.5 (formerly known as Orcas), native, high level support for this functionality is now included, and is located with the System.AddIn namespace. This namespace contains a set of types that encapsulate the various building blocks of add-in infrastructure development, and are designed to be easily and quickly used by you to build add-in support for your applications.
.NET Framework 3.5 add-in support is divided into two layers. The first and most important layer provides the foundation for building add-in extensibility into your applications, and addresses a wide variety of scenarios that generally involve a host application exposing functionality for an add-in to integrate with (although functionality can be exposed by the add-in as well). This foundation is known as the CLR Add-In Model, and you can find out plenty about it in the CLR Add-In Team’s blog. Additionally, check out these great MSDN Magazine articles to provide some background: .NET Application Extensibility Part 1 and .NET Application Extensibility Part 2.
The second layer is implemented by WPF, and extends the CLR add-in model to allow host applications (standalone and XBAP) to display UIs provided by add-ins (and vice versa), on top of the extensive abilities provided the CLR add-in model. Now, WPF developers can address a slew of interesting scenarios that include:
- Messenger-style buddy bots.
- A training application hosting third party training modules.
- A news reader application hosting advertising.
The next drop of the WPF SDK, due soon, will include a bunch of documentation for building add-ins in WPF. For now, though, I hope the attached sample and How To (from the next SDK drop) provide a useful starting point.
Note – In .NET Framework 3.5 RTM, the name of the VisualAdapters class and its members will change. See this post for more information.
Comments
- Anonymous
November 12, 2007
Hola! I just returned from TechEd 2007 held in Barcelona, Spain. Barcelona is a beautiful city with incredible