I\'m developing a .NET 3.5 C# desktop application. It should be extensible via plug-ins.
Are there any articles etc. discussing the differences between MEF and Mono.AddI
[NOTE: I work on MonoDevelop, which uses Mono.Addins, but I discussed the differences between MEF and Mono.Addins extensively with Glenn Block from the MEF team last week]
MEF is based on composing code, though the underlying abstractions are very flexible. In contrast, Mono.Addins is based on a tree of metadata, where you can plug data/metadata/code into a rich schema of your definition, so extensions can add data/metadata as well as code.
Mono.Addins gives you an addin management/packaging/repository/update system out-of-the box. For MEF, at this point, you would have to build your own.
MEF has a slightly lower barrier to entry, and a lot more design work has gone into its usability and underlying abstractions. In addition, it's part of .NET 4, so it'll have a much bigger community of users developing with/for it.
At this point, if you need to plug in data/metadata as well as code and you want a ready-made packaging system, I'd recommend Mono.Addins, otherwise I'd recommend MEF. Going forwards, it's likely that Mono.Addins' features will be implemented on MEF, so there will probably be a migration path towards MEF.
I believe Hanselminutes Show #181 has some discussion about Mono.AddIns and what it brings to the table.
While scouring the web I also found this discussion which highlights a difference in how these two frameworks currently handle catalog caching.
I investigated both and decided to go with MEF, mostly because it's going to be released as part of .NET 4 so there will automatically be more support, discussion, and development surrounding it. Also, MEF seemed to be able to do everything I needed using attributes right in the code, and Mono.AddIns required some metadata files, if I remember correctly.
EDIT: If you'd like to see the result of my efforts at using MEF to build an extensible application framework, I've open sourced it, and given it a name: SoapBox Core.