views:

59

answers:

1

Hi all,

I'm developing a component (HttpModule) that's used by a number of web applications on a .NET website, and I want the component to be easily maintainable. I've come up with something outlined below but wanted to see if there were any positive/negative thoughts or general feedback on the implementation, as I'm not 100% familiar with Assembly loading, especially in terms of memory overhead.

(I don't really want to do this: http://stackoverflow.com/questions/716483/create-your-own-net-assembly-cache)

The lightweight HttpModule itself is in the GAC and referenced from the site's root web.config. On each request it opens a text file (stored in the web's root/bin) that contains just a strong named's assembly name (e.g. "My.MyLibrary, Version=1.1.0.0, Culture=en, PublicKeyToken=03689116d3a4ae33") and then checks the current AppDomain to see if it is already referenced (iterates over GetAssemblies()). If not, it then calls Assembly.Load to load myLibrary and uses basic Reflection to Invoke() a custom method in My.MyLibrary that actually does the intended processing work of the HttpModule.

My.MyLibrary itself is also in the GAC. To upgrade the app without any app restarts, put a new version in the GAC, and just edit the string in the text file. I'm using the text file because a) it's fast and b) I didn't want to have to update a machine/web.config and cause a recycle to redirect the HttpModule to use a new version of My.MyLibrary. It seems to work okay. The old version can be uninstalled from the GAC when it's finally ready to be. So hopefully the only time an app pool/iis reset would be needed would be to change the HttpModule part.

Any replies much appreciated!

-Will

A: 

Personally I would say if you can avoid using any late binding it would be better, but as you want to be able to have the freedom to just throw a new assembly at your application then it does seem like late binding makes sense.

With regards to your method of storing and retrieving the list of assemblies, I would use an XML object and load it from the file. You will find adding extra information to it simpler this way, otherwise you will have to maintain your own file format.

You may also want to consider adding some code to catch errors generated from these assemblies, unload them and put a flag in your file telling your HttpModule not to load it until it has been updated.

Robert
Thanks!The code ultimately run by the HttpModule is quite simple so when I get to test/pre-prod I'll run some tests and see if the flexibility is worth whatever performance hit I get from late binding.Yes, I thought of expanding the text file to an XML file but mostly wanted f/back on the general architecture of loading a commmon DLL for a website without needing an app restart. Most articles/posts/comments I've found online seem to imply it's not possible, so I was wondering if there were any other methods or there were any obvious oversights/issues with the method I'm planning to use.
will.i
I don't think I'm going to be unloading the assembly because I don't want to create any new AppDomains. The HttpModule has blanket error handling in it.
will.i
First i'd say its not a good practice to have an architechture where you just add anything without a solid plan to remove it when it is finished with, this is because at some point in the future you will encouter resource problems and have to restart you application to at least free up memory.Dynamic loading of assemblies is posible in ASP.Net as you have full access to the .Net framework. How are you going to use the assemblies you load?Will they be acting like the standard HttpModule's but without the need to restart the app domain?
Robert