GetAssemblies missing dll's

I have a couple ASP.Net MVC web applications that allow additional functionality by dropping new class library dll's into the bin directory.  This causes new options, tools, products, workflows, etc to be enabled to the user with just a pushing out a new class library.  We've moved away from using an DI/IoC tool (StructureMap/Castle Windsor) because of seeing some memory leaks and having some maintenance issues of the xml files needed to use them.

Instead I decided to go the route of using existing functionality built into the .Net framework.  There is this nifty little static method AppDomain.CurrentDomain.GetAssemblies() which:

Gets the assemblies that have been loaded into the execution context of this application domain.

So, I figure this being ASP.Net, all the dll files in the bin directory would be loaded up, right?  I run the solution and a bunch Assemblies are returned (mscorlib, System.Web.Mvc, Stuff.I.want.dll, More.Stuff.I.Want.dll) page loads and I can see everything it there and happy. A bit more testing happens and then check-in so it gets put out on the web server.
I run through some testing there to make sure there is no real differences between IIS7 and Visual Studio development web server.  Everything looks great. I've removed some external dependencies, lowered the memory footprint, and eased readability. Fantastic! Time to turn it over to have others really kick the tires.

A couple hours go by and then it happens. "Hey Paul! I'm not seeing any of these options I had the last time I opened the page." So I look, the dll's are there.  There were no other code changes to remove them. Let's run local.  Everything looks fine.  I check that results from this particular call are being cached. Everything seems fine.  I change some methods from static to instance, just in case, and deploy.

Again, everything is going along just fine, until the next morning. "Paul. Seriously, are you messing with me? These options are gone again." Me: "%&$(*$%" Directory looks fine. Ok, going to move some stuff out of extension methods and directly into the main assembly for this backend assembly. Lather, rinse, repeat.

Time passes... "Paul, WTF?" Me: "Are you friggin kidding me?" Nothing, NOTHING, is static now in my code.  Nothing is in an extension method, I am very close to having all this functionality in one big DoThisCrap method.

To the Googles!!!

You remember that "Gets the assemblies that have been loaded into the execution context of this application domain." part earlier? Yeah me neither.

So what was happening, as best as I can tell, was the fresh code right after a deployment (or every time I opened in the VS dev server) ASP.Net loaded every dll in the bin as I hoped.  On subsequent page visits, ASP.Net learned that some files were not needed on the last load and no code was directly instanciating them so they weren't loaded. This means they didn't show up.

What to do? Well, we can get the current directory from AppDomain.CurrentDomain.BaseDirectory property.  From there it's a simple System.IO.Directory.GetFiles call to plow the directory with various search options.

/*
this can be pointed to specific sub folder using string.format
*/
var path = AppDomain.CurrentDomain.BaseDirectory;

/*
you can add file name matching criteria here if the assemblies you are looking for match a naming convention
*/
var files = Directory.GetFiles(path, "*.dll", SearchOption.AllDirectories);

and now we can perform logic on the files array.

Since we are looking directly at a folder path, there is no issue of whether previous runs loaded the assemblies into the AppDomain.  However, there is the additional cost of going to disk to get results.

Congratulations! You just broke the team!

Infighting. Every team has it to some point. The testing team complains that the developers screwed up the application. The developers blame the business analysts for incomplete/incoherent requirements. The BA’s blame the testing/dev groups for misinterpreting the requirements or interpreting them instead of asking for clarification. The project manager blames everyone for slipping deadlines.

Some conflict is expected within any group. There are, however, lines that need to not be crossed. We are all part of this thing for a reason. Let’s give each other a bit of respect and we can get through our day-to-day much easier. Mutual respect is required for all silos/individuals on the team.

Saying to external teams that you have no confidence in one of the internal teams to deliver on what they are paid to do is incomprehensible. Questioning a team members motives on how they spent a vacation day that was scheduled weeks in advance is ludicrous. Demanding that other teams work nights and weekends when you don’t do the same is selfish. Throwing a fit when an individual says “NO!” to working over a holiday weekend because you don’t celebrate the same holiday is appalling.

Below is a brief list of what is being halted whenever I have to deal with this infighting:

• I investigate new methodologies and technologies
• I scrutinize every line of code
• I monitor data page utilization
• I remove redundancy
• I optimize methods and queries
• I normalize datasets
• I take long running processes down to a tenth their initial time
• I plan for scale
• I visualize data sets and workflows the way most people see pictures
• I read countless blogs, tweets, message boards
• I teach more junior developers how to use existing frameworks
• I collaborate with my peers
• I document the system
• I design new features
• I prioritize deliverables
• I fix bugs
• I update data
• I spec hardware
• I evaluate new software
• I verify we are licensed properly
• I write .Net
• I read Java
• I understand PHP, ForTran, COBOL and more
• I relate the data
• I connect the networks
• I make the impossible possible
• I tell you when the impossible really is impossible
• I can *DD the hell out this shit
• I can make fat objects light and anemic domains rich
• I’ve came in early, stayed late, worked weekends and holidays

I am Paul Montgomery. I am good at what I do. I do this shit for a living because I am good at it. I am a pretty damned big deal. I do all I can to surround myself with highly capable people. I will not tolerate treating any member of my team without respect.