We are developing a CMS in ASP.NET. We love the idea of add-ons (like in Wordpress, where any developer can add a menu button or a widget) and would like to enable developers to do the same with our system.
However I think that the fact that C# is a compiled language is an obstacle in the way of add-ons.
Am I right? Or is there a way to create add-ons for a ASP.NET application?
I'm not sure for ASP.NET specifically, but in the only compiled programming language I know (Objective-C/Cocoa), there's the concept of Bundles that can be loaded dynamically. I'm not sure how that works on the backend, but I'd guess that there is some similar system for C#/ASP.NET.
I don't know how it's done in Wordpress, but there should be many ways. You can allow developers to upload their assemblies with compiled code or you can allow them to upload code in C# or IronPython or anything that supported and compile it dynamically. Maybe you can use WebParts for your task.
Microsoft has created the Managed Extensibility Framework (MEF), specifically for this problem: providing .NET plugins for .NET applications. It is the framework that (future versions of) Visual Studio use for writing managed plugins.
However, please consider using a dynamic scripting language for this! Problems like this are exactly what they are specifically designed for. If you host the Dynamic Language Runtime in your application, it not only means that your users can extend the application in a scripting language, but even in any dynamic language (scripting or otherwise) for which a DLR implementation exists: Ruby, Python, Smalltalk, Scheme, JavaScript, PHP, you name it. Biggest disadvantage: the DLR hasn't been released yet.
The fact that C# is a compiled language isn't a problem at all. In fact the .NET framework should make it relatively easy to load other code (just as Java does, for the same reason). Look into the Managed Extensibility Framework, which is all about loading Add-Ons in managed code.
In C#, you can create any assemblies, link them as DLL files and then do whatever you want.
The usual case would be to define some kind of Plugin Interface which must be implemented by all the plugins.
Then you can load all plugins from the filesystem (by iterating over the plugin DLLs), find the class inside which implements the interface, instantiate it and work with it.
If you want to provide plugins with unloadability and security, you could create an application domain and load the plugins to that, increasing complexity, but also increasing stability (a bad plugin won't crash your app).
Please ask more specifically if you want a specific answer :-)
It's not too difficult to put hooks in place. You have to define in advance where the add-on features will appear. For example: when drawing a menu you can use reflection to search other dlls (with specific names and locations) for a "BuildMenu" function. You'll be defining the API for this function signature. It may have to return a list of items to be added to the base menu items collection.
It's not an obstacle at all. MEF has already been mentioned, you could also use: