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.
I love technology! One of the things I've seen a lot lately is Abstract Computing (I can't think of a better way to describe it?)
You can run one or more simulated computers inside your current computer. That's called VirtualPC.
You can connect to a computer in another room and work on it like it's your current machine. That's called Remote Desktops (or Terminal Services).
You can use the same mouse, keyboard and clipboard on more than one machine(even if it's running a different operating system!). That's called Synergy.
Not to mention that you can administer IIS servers and SQL databases for any server from any workstation. I think Active Directory gives us that ability.
Throw a dual monitor into the mix, then it becomes quite a task to remember what computer you're working on! Fun stuff.
SPIT - Spam over Internet telephony.
Bruce Schneier has written an interesting article on VoIP spamming and spamming in general. Check it out.
Isn't it terrible how another technology is being exploited by spammers? Yes, there's more important things to worry about (war, famine and all that), but that doesn't make this spam “war” any less annoying.
I've written a lot of custom ASP.NET server controls. But my work has evolved enormously during the last two years. Mainly because server control documentation is very sparse. I usually start doing things the wrong way, then only later learn what the correct way is.
For example: I started out by Response.Writing any custom javascript in the OnRender method. Then later I read that this should rather be done in OnPreRender using Page.RegisterStartupScript.
So little by little my code is improving. However, I've never found a comprehensive MSDN document or website article that explains server control development properly. That leaves me with having to take tidbits from hundreds of websites to put the server control puzzle together.
If anyone can point out a good (comprehensive) server control e-book or articles, I'd be happy to publish the link on a blog post. I'm sure it'll help a lot of developers that make the same mistakes and struggle with the same problems.