ANNOUNCE: Mono.Addins 0.1
Lluis Sanchez
I'm pleased to announce the release of Mono.Addins.
Mono.Addins is a generic framework for creating extensible applications,
and for creating libraries which extend those applications.
Mono.Addins has been designed to be easy to use and useful for a wide
range of applications: from simple applications with small extensibility
needs, to complex applications which need support for large add-in
structures.
This new framework intends to set an standard for building extensible
applications and add-ins in Mono. I've created a mailing list I
encourage you to subscribe if you have suggestions or questions about
the library:
http://groups.google.com/group/mono-addins
The main features of Mono.Addins are:
* 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.
If you are interested in knowing more about Mono.Addins, this document
explains the library basics and some examples:
http://www.mono-project.com/Introduction_to_Mono.Addins.
If you are *really* interested and want to know in detail everything
about Mono.Addins, see: http://www.mono-project.com/Mono.Addins.
You can download a tarball from:
http://www.go-mono.com/sources/mono-addins/mono-addins-0.1.tar.gz
Latest from SVN at:
svn://svn.myrealbox.com/source/trunk/mono-addins
Enjoy!
Lluis.
Sanford Armstrong
> Hi,
>
> I'm pleased to announce the release of Mono.Addins.
This sounds super cool. Is there any guarantee of stability in the
API at this point?
Thanks,
Sandy
Lluis Sanchez
escriure:
I can't give full guarantee, since the library has just been announced,
and there may be changes based on the feedback we get from developers.
However, I feel that there won't be important changes, maybe some
additions.
Lluis.
Stojance
This library seems very cool! I like it. I might use it for my own
applications 'cause I needed Add-ins for it but had Nooo idea how to
do it. This simplifies things a lot!
Bye,
Stojance
freu...@gmail.com
Hello Lluis,
Your surname suggests to me you are from spain, like me. I'm
interested in participating in your project because I am making a
small editor project extendend by plugins. This is:
http://sourceforge.net/projects/chikin/
The state project is very very pre-alpha and I need a plugin system.
Best regards
Daniel Fernández
Lluis Sanchez
>
> Hello Lluis,
>
> Your surname suggests to me you are from spain, like me. I'm
> interested in participating in your project because I am making a
> small editor project extendend by plugins. This is:
>
> http://sourceforge.net/projects/chikin/
>
> The state project is very very pre-alpha and I need a plugin system.
Good to know! Please take a look at the library and the documentation,
and if you have any question feel free to ask in this list.
Lluis.
tcmichals
Good work, one issue also I'm trying to over come is saving settings
from within the plug-in.
For example, there is a default settings and it loads the application,
using the xml files. the user changes some stuff and saves the
settings out, these settings also include, options not to include
other plugins and some of the default settings to user defined
settings. But, I want to use the plugin framework to re-load the
settings. So can the plugin framework do this?
Antonello Provenzano
I'm not directly interested in contributing to the project (I'm still
figuring me out how to implement LINQ support), but a friend of mine
(Matthijs) has been working on a similar project called NApf since
before MS published AddIn support in the 3.5.
You should think about it.
Cheers.
Antonello
On 3/26/07, Lluis Sanchez <ll...@ximian.com> wrote:
> _______________________________________________
> Mono-list maillist - Mono...@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
nick.van...@gmail.com
I've been looking around recently for information about a plugin
architecture and came across some helpful documents.
One of the things they all recommend is the use of appdomains for the
loaded plugins.
Is this supported in Mono.Addins?
Would there be any side effect in also using this under windows
and .net framework 2.0?
Thanks, Nick
Lluis Sanchez
I'm sorry but I don't understand what you want to do. Maybe an example
would help.
In any case the framework does not provide support for storing settings,
that should be provided by the host application. However, it does
provide support for enabling/disabling add-ins. It can be done using the
AddinRegistry class, accessible from AddinManager.Registry.
Lluis.
Lluis Sanchez
nick.van...@gmail.com va escriure:
> It looks really nice.
> I've been looking around recently for information about a plugin
> architecture and came across some helpful documents.
> One of the things they all recommend is the use of appdomains for the
> loaded plugins.
> Is this supported in Mono.Addins?
Right now it is not supported, but it's something we might add if people
need it. Notice that using app-domains is not always possible. For
example, if the add-in needs to extend a gtk# user interface (which is a
very common case), it won't we able to use app-domains since gtk# can
only run in the main domain.
> Would there be any side effect in also using this under windows
> and .net framework 2.0?
I haven't tried it, but it should work as it is a fully managed library.
>
> Thanks, Nick
>
>
> >
Lluis Sanchez
escriure:
> Lluis,
>
> I'm not directly interested in contributing to the project (I'm still
> figuring me out how to implement LINQ support), but a friend of mine
> (Matthijs) has been working on a similar project called NApf since
> before MS published AddIn support in the 3.5.
>
> You should think about it.
There are some similarities between Mono.Addins and NApf, although the
focus is different.
Mono.Addins is just an add-in engine. It intends to be as small as
possible, and avoids imposing an architecture on the host application.
All the effort has been focused in building an add-in engine which is
fast, memory efficient and scalable (a host can efficiently handle
thousands of add-ins).
On the other hand NApf is more focused on building an application
framework. It has an add-in engine similar to Mono.Addins (since it is
based on the SharpDevelop engine), although it isn't probably as
optimized as Mono.Adidns (it's just a guess, since I haven't analyzed
the code). In addition to add-in engine it offers other modules for
managing settings, logging, and other high level UI components. That's
not covered in Mono.Addins and never will.
Lluis.
Federico Di Gregorio
> In addition to add-in engine it offers other modules for
> managing settings, logging, and other high level UI components. That's
> not covered in Mono.Addins and never will.
I understand you want Mono.Addins to be lean and clean but what about
supporting at least the management of addin settings? You said in a
previous email that that should be done in the application and I prety
much agree, but talking about reusable and cross-application add-ins it
doesn't make sense to rewrite the settings management code in every
application that wants to use a "generic" add-in.
federico
--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer f...@debian.org
INIT.D Developer f...@initd.org
Best friends are often failed lovers. -- Me
Lluis Sanchez
escriure:
> Il giorno mar, 27/03/2007 alle 13.42 +0200, Lluis Sanchez ha scritto:
> > In addition to add-in engine it offers other modules for
> > managing settings, logging, and other high level UI components. That's
> > not covered in Mono.Addins and never will.
>
> I understand you want Mono.Addins to be lean and clean but what about
> supporting at least the management of addin settings? You said in a
> previous email that that should be done in the application and I prety
> much agree, but talking about reusable and cross-application add-ins it
> doesn't make sense to rewrite the settings management code in every
> application that wants to use a "generic" add-in.
When I was talking about Mono.Addins not supporting settings management,
I was talking from the point of view of an application framework. For
example, MonoDevelop provides classes for managing settings, which are
used in all the libraries that compose MD to store settings. Those
settings are stored in an XML file in the MD config directory.
Mono.Adidns will not implement this kind of functionality, since
different applications may have very different needs.
However, it might make sense to support a storage service at add-in
level. That is, add-ins may need to store somewhere configuration or
status information. This information would be add-in specific and would
be deleted if the add-in is uninstalled. This storage service would be
only for add-ins, and would be completely hidden to the host, since it
would be an implementation detail of the add-in.
Lluis.
Nick
Microsoft has been working on?
http://blogs.msdn.com/clraddins/default.aspx
I have used their framework a little, and it seems very extensive, and
I think with a little work we can get this .NET 3.5 feature knocked
off. Since it is officially going to make it in Framework 3.5.
I would love to help you out some, please let me know if you need any
help.
Lluis Sanchez
> Is this eventually going to be the mirror of the CLR AddIns that
> Microsoft has been working on?
Nope, Mono.Addins has a different set of features, and it is more
generic. It would be really hard to build for example MonoDevelop on top
of System.AddIn. The problem is that System.AddIn is based on the
concept of dynamically discovering and instantiating types in an
(optionally) isolated execution context. Mono.Addins is based on a more
generic concept of extension, so you can dynamically discover and load
extensions which are not just 'types' but they can be data of any kind
(for example, an extension could be an image).
We could eventually build System.AddIn on top of Mono.Addins, but I'm
not sure would would get any benefit from that.
>
> http://blogs.msdn.com/clraddins/default.aspx
>
> I have used their framework a little, and it seems very extensive, and
> I think with a little work we can get this .NET 3.5 feature knocked
> off. Since it is officially going to make it in Framework 3.5.
Ststem.AddIn will soon or later be implemented, but that's not the main
goal of Mono.Addins.
Charlie Poole
> I'm pleased to announce the release of Mono.Addins.
>
> Mono.Addins is a generic framework for creating extensible
> applications, and for creating libraries which extend those
> applications.
>
> Mono.Addins has been designed to be easy to use and useful
> for a wide range of applications: from simple applications
> with small extensibility needs, to complex applications which
> need support for large add-in structures.
>
> This new framework intends to set an standard for building
> extensible applications and add-ins in Mono. I've created a
> mailing list I encourage you to subscribe if you have
> suggestions or questions about the library:
> http://groups.google.com/group/mono-addins
Great, you're just in time for me to use it!
FYI, NUnit 2.4 has a somewhat adhoc approach to addins that I planned to
replace with a complete add-in-based design in 3.0. I was going to look at
the SD/MD addin structure and work from that, but it makes more sense to
have a separate addin framework that will have wider use and contribution...
>
> The main features of Mono.Addins are:
>
> * Supports descriptions of add-ins using custom attributes (for
> simple and common extensions) or using an xml
> manifest (for more
> complex extensibility needs).
This is especially good for me. I can see some people writing adhoc add-ins
that are right in their test assemblies, while others will want to create
truly separate add-ins.
> * 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.
Qs:
Is this MIT-licensed?
Is it intended to work on .Net as well as Mono?
Charlie
> If you are interested in knowing more about Mono.Addins, this
> document explains the library basics and some examples:
> http://www.mono-project.com/Introduction_to_Mono.Addins.
>
> If you are *really* interested and want to know in detail
> everything about Mono.Addins, see:
> http://www.mono-project.com/Mono.Addins.
>
> You can download a tarball from:
> http://www.go-mono.com/sources/mono-addins/mono-addins-0.1.tar.gz
>
> Latest from SVN at:
> svn://svn.myrealbox.com/source/trunk/mono-addins
>
> Enjoy!
> Lluis.
>
>
>
> _______________________________________________
> Monodevelop-list mailing list
> Monodeve...@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
Lluis Sanchez
postings).
> Great, you're just in time for me to use it!
>
> FYI, NUnit 2.4 has a somewhat adhoc approach to addins that I planned to
> replace with a complete add-in-based design in 3.0. I was going to look at
> the SD/MD addin structure and work from that, but it makes more sense to
> have a separate addin framework that will have wider use and contribution...
That would be awesome! Please take a look at the library and post any
questions you may have.
>
>
> >
> > The main features of Mono.Addins are:
> >
> > * Supports descriptions of add-ins using custom attributes (for
> > simple and common extensions) or using an xml
> > manifest (for more
> > complex extensibility needs).
>
> This is especially good for me. I can see some people writing adhoc add-ins
> that are right in their test assemblies, while others will want to create
> truly separate add-ins.
I would be interested in knowing specific uses cases for this, to see
how Mono.Addins fits on them.
>
> > * 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.
>
> Qs:
> Is this MIT-licensed?
Yes.
> Is it intended to work on .Net as well as Mono?
Yes, that's the plan.
Lluis.
Charlie Poole
> attributes (for
> > > simple and common extensions) or using an xml
> manifest (for
> > > more
> > > complex extensibility needs).
> >
> > This is especially good for me. I can see some people writing adhoc
> > add-ins that are right in their test assemblies, while others will
> > want to create truly separate add-ins.
>
> I would be interested in knowing specific uses cases for
> this, to see how Mono.Addins fits on them.
I'll chime in as soon as I have more of a roadmap for NUnit 3.0.
Something not mentioned that would be very useful to me: addins that
are loaded only when the executing CLR is at or above a certain level.
Charlie
Pedro Alves
Lluis Sanchez
Sharique
keep Up my friends.
------
Sharique