Different Approaches to Add-In Discovery [Jesse Kaplan]

re: Different Approaches to Add-In Discovery

Simone — Mon, 29 Jan 2007 06:33:51 GMT

Hi, my name is Simone, and I'm a member of Subtext core team, and my main role at the moment is developing the support for plugin (or add-in) extensibility.

I just found your blog and I'm subscribing to it immediately.

re: Different Approaches to Add-In Discovery

Gary — Tue, 20 Feb 2007 23:20:04 GMT

Hello Simone,

You might want to look into VSTA

Visaul Studio Tools for Applications implements System.Addin -based application exstensibility and optionally provides the end user with the VSTA IDE to author their own addins.

Regards,

Gary Depue, Summit Software

re: Different Approaches to Add-In Discovery

William Sullivan — Fri, 23 Feb 2007 19:29:09 GMT

Friggin great article. I'm getting deep into extensible architectures right now, so this blog is now #1 on my roll. One point, however--the first example has the line

foreach (Assembly asm in assemblies)

but the variable assemblies isnt' defined in the method. Could you fix the example to include its definition? Thanks.

re: Different Approaches to Add-In Discovery

William Sullivan — Fri, 23 Feb 2007 19:39:50 GMT

Jumping ahead... Part of my research into add-ins included writing one for Lutz' Reflector. His addin architecture consists of a DLL that contains a class that implements the plugin interface IPackage. This interface defines a single method--Load--which has a parameter of type IServiceProvider. Within this method, the addin author requests service managers by passing their type (i.e., GetService(typeof(IWindowManager)) for the window manager), then uses these managers to register different components of the addin (such as event handlers, UI elements, menu items, etc) with Reflector.

Is this similar to how to the discovery method of the AddIn libraries? If not, what are the pluses and minuses of this method? Thx!

re: Different Approaches to Add-In Discovery

CLR Add-In Team — Sat, 24 Feb 2007 03:50:04 GMT

For the above examples the assemblies are typically found using code very similar to the following:

String[] files = Directory.GetFiles(path, "*.dll");
List<Assembly> assemblies = new List<Assembly>();
foreach (String file in files)
{
assemblies.Add(Assembly.LoadFrom(file));
}

As far as Lutz's reflector there are actually two different questions here. The first is about how reflector actually discovers add-ins and the second is about what sort of object model the application provides.

On the discovery question, based on the docs online about writing reflector add-ins, it looks like it is using something very similar to example #1 except the user may point reflector at a specific assembly rather than a directory.

As far as the object model is concerned the pattern reflector uses is actually very common. With this object model the host is actually providing a service to the add-in rather than the other way around. The host activates the add-in, passes it a reference to the host object, and then lets the add-in do its thing until shutting it down. Office and Visual Studio use the same basic pattern for many of their extension points: see IDTExtensibility2. Our System.AddIn model is completely agnostic and lets the host define any object model it wishes. We don’t currently have samples demonstrating this but they are coming.

--Jesse Kaplan

re: Different Approaches to Add-In Discovery

William Sullivan — Mon, 26 Feb 2007 16:18:38 GMT

Cool, thanks.

Another question--AddIn vs. the provider model of ASP.NET 2.0. The setup would be similar to the third pattern of discovery (manifest) of the first example, but what about the implementation?

Keep it coming guys, I love this stuff.

Behind the Scenes of Add-In Discovery in the Orcas System.AddIn [Jesse Kaplan]

CLR Add-In Team Blog — Thu, 15 Mar 2007 19:57:38 GMT

Details about the System.AddIn’s Implementation of Add-In Discovery Last time we discussed several common

re: Different Approaches to Add-In Discovery [Jesse Kaplan]

Dod — Sun, 13 Jan 2008 16:40:21 GMT

Is it possible to query for add-ins using the custom attribute approach?

I was trying to define some custom attribute named "MyAddInCategory(string)", and to put it on the addin clas where I'm implementing the abstract view class.

Unfortunately, it seems as if the proxy does not forward the attribute, so when I'm creating an instance of the package later on and trying to GetType().GetCustomAttribute(typeof(MyAddInCategory)... , I'm getting no attributes.

Do you have an easy way to overpower this?

How to: Build System.AddIns using Pipeline Builder

Harry Soetardjo — Sat, 05 Apr 2008 04:19:19 GMT

How to: Build System.AddIns using Pipeline Builder