ASP.NET Plugin Architecture
I've spent the last couple of weeks working on an ASP.NET plugin architecture. Our application(web-based) allows the user to use “plugins”. A plugin can be a simple class that executes some code when a button is clicked, or the plugin can actually be a small website with its own custom pages.
If you want to write ASP.NET plugins that are simple classes, the process is straight-forward. I suggest deploying the plugin assemblies into a custom folder. Add the <probingPath> section to your web.config file to tell the CLR where to look for your assemblies. Scott Hanselman has written a good article on how to do this.
If you want to write ASP.NET plugins that use custom pages - Beware! There's a couple of pitfalls you might come accross.
Disclaimer: The advice I give here is not necessarily the correct advice. It's only what I've learn throught a couple of weeks through trail and error. Hope it helps out someone with the same problems. Below are some of the important things I've learnt...
1. The BIN folder
When you load a custom aspx page, the custom page needs to find it's assembly. The CLR looks for the assembly in the current web application's 'bin' folder, then it checks the GAC. Naturally you'd want to put the plugin assembly in the application's 'bin' folder.
There is one catch: when your session state mode is InProc, you cannot deploy plugin assemblies to your 'bin' folder at run-time! When IIS sees that the bin folder has been altered, it silently restarts your web application. You'll lose all your session variables without warning.
One way to get around this is to set your session state mode to SQLServer or StateServer (check out this article for more information). When you do this, make sure that the objects you store in session state are Serializable. Note that these two modes are also extremely slow compared to InProc session state management.
2. The plugin folder
You can deploy your 'plugin' application to a sub-folder in your root application. For example: http://localhost/MyApplication/plugins/MyPlugin.
This folder should contain your custom aspx, js, asax... files (remember, the assemblies are sitting in the root application's 'bin' folder). When you do this, the sub folder should not be configured as an IIS application. If the sub folder is turned into an IIS application, you won't be able to share session variables between your plugin and your root application.
3. The web.config file
Your 'plugin' application will inherit your root application's web.config settings. For this reason, your plugin application's web.config file should only contain the bare minimum settings. I only keep the <authorization> section to configure authorization in my plugin files.