Reflect

I've discussed my DataXplorer here before. It's a configurable, searchable data page with a result set and a grid. You can configure a context based menu per item to perform a redirect to a page and set either session variables or query string variables from the row selected.

I've recently updated it to include the ability to configure a menu that is not context based, but goes with our paradigm of each row having a check box to signify a selection. Therefore you can now perform some action against more than one row at a time. But wait, there's more.

I've also added a top row (not on the grid, but the page) button based menu system. Each menu corresponds to a configuration to which you can load an assembly, build parameters (both static and items on that particular row) and execute a method. You also get a feedback object which tells you of the success or failure of your action. I learned a lot about reflection by doing this.

One thing I learned is that if you don't do some concurrency check to validate that you don't already have the assembly loaded into your Application Domain you can get bloated fast. Speaking of Application Domains, in asp.net it's a bear. Your application runs under it's own app domain, which is how asp.net manages to isolate the memory of app from each other. All of your assemblies are loaded into the app domain, which is why it's so much faster. However, once loaded always loaded (I really wish there was a way to recycle certain assemblies on a sliding contention timeout), so to unload an assembly you have to unload the app domain. Bad idea.

What I ended up with is a method that checks all the assemblies that are loaded in the current app domain for the one I am dealing with at runtime. If I can't find it, then I load the assembly. I have read all sorts of blogs and news postings that really push you towards building another app domain and loading everything you need there, then tearing it down when your execution is done. It's a bad, bad idea.

Think about it. In this case the same assembly may be loaded and unloaded 15 times in 5 minutes by one user. It doesn't scale well. Plus there are all sorts of issues about assembly caching and so on. If you do it using the methodology I did, then asp.net manages it all. Your app runs a little heavy, but for this purpose it's actually better. I can now make extremely small assemblies (my first one was 16k compiled in debug mode) that target specific functionality. Plus you can reuse functionality that the app already knows about. It's a win win. yay yay.

Now here comes the cool part: I am loading an assembly, defining what the method is I want to call and then dynamically building its parameters and executing the method. I have this rolled out to about 100 users and it's working perfectly so far.

I'll add some designs when I have them polished a bit.