Mono.Addins!

Today I finally announced Mono.Addins, a generic framework for implementing extensible applications in Mono.

I've been maintaining the MonoDevelop add-in engine for almost two years now. This engine is based on the SharpDevelop add-in engine, which took ideas from Eclipse. At some point I decided that it would be interesting to be able to reuse the engine in other applications, so I decided to take it out of MD, move it to an independent library and make it more generic. That became Mono.Addins.

This is the list of features of Mono.Addins taken from the announcement:

• Supports descriptions of add-ins using custom attributes (for simple and common extensions) or using an xml manifest (for more complex extensibility needs).
• Support for add-in hierarchies, where add-ins may depend on other add-ins.
• Lazy loading of add-ins.
• Provides an API for accessing to add-in descriptions, which will allow building development and documentation tools for handling add-ins.
• Dynamic activation / deactivation of add-ins at run time.
• Allows sharing add-in registries between applications, and defining arbitrary add-in locations.
• Allows implementing extensible libraries.
• In addition to the basic add-in engine, it provides a Setup library to be used by applications which want to offer basic add-in management features to users, such as enabling/disabling add-ins, or installing add-ins from on-line repositories.

Reusing an add-in engine has many advantages. It's not only about reusing the library, but it also allows reusing an add-in model. Developers will be able to reuse knowledge and development tools to develop add-ins for different applications. Mono.Addins is specially good for this because it encourages self-documentation of add-ins, and it provides an object model for reading add-in descriptions, so building documentation and development tools based on it will be easy.

However, creating an add-in engine that fits all application needs is not trivial. Different applications will have different extensibility needs. For example, in MonoDevelop some add-ins need to extend other add-ins, so add-in identity and versioning is an issue to take into account. Lazy loading of add-ins is also important, since and IDE may integrate many tools, but not all of them are needed at the same time. MD also needs to provide complex extension points, such as the solution tree pad, build pipelines or hierarchical menus. MD describes those extension points using XML manifests.

Other more simple applications will have more simple needs. For example, an application may just need to load types from some assemblies copied to some directory. Mono.Addins can also be used in this case without adding development complexity. Instead of using XML manifests, extensions can also be declared using custom attributes, and there is no need to assign identifiers or versions to add-ins, since there won't be add-ins extending other add-ins.

What's interesting is that both applications will be using the same add-in model, and it will be possible to use the same API, documentation and development tools for both cases.

I'd like Mono.Addins to set an standard for building extensible applications in Mono. That's why I'd like to get feedback from applications developers about the library and about add-in development in general. I created a mailing list to collect this feedback: http://groups.google.com/group/mono-addins. If you are developing an application which can be extended by add-ins, please take a look at Mono.Addins and say something!

To know more about Mono.Addins you can read the Introduction to Mono.Addins.
A more detailed guide on using the library can be found here.
And the source code is here.

Enjoy!