views:

27

answers:

2

I've come across an intriguing problem. I have an application made of several assemblies. I installed the application but forgot one small non essential assembly. The application appeared to start and work fine until I hit a method that required the use of that assembly. As you might've already guessed I see the "Could not load file or assembly 'Blah, Version=1.0.0.0, Culture=neutral, PublicKeyToken=Blah' or one of its dependencies. The system cannot find the file specified." Exception.

No surprise there right? Yes, the installer could be fixed and my problem goes away but I wanted to see if there was a programmatic way to do it. So I tried wrapping the code that uses the non essential assembly in a try block and release the expensive resource in the finally block like so:

public void MethodA()
{
    try
    {
        // Do stuff with non essential assembly
    }
    finally
    {
        // Release expensive resource here
    }
}

Thinking the JIT compiler will throw from within the try block to eventually return control to the finally block and my resource is released. It turns out the JIT compiler throws at the point the method is called.

I've thought of moving the finally block higher in the call chain but this method is being called from hundreds of places. I've thought of using Assembly.Load for the non essential assembly but the idea of having to use reflection makes me feel dirty.

Is there a way to make the finally block execute in this case without restructuring too much or having to take a shower, I mean, use reflection?

+1  A: 

Define another method that does your stuff with the nonessential assembly.

Call it from Method A.

So:

public void MethodA()
{
    try
    {
        MethodAImpl();
    }
    finally
    {
    }
}
Anon.
This is what I've had to do but I was wondering if there was little known compiler hint.
tgeros
+1  A: 

If the assembly is non essential then there is no problem with using Assembly Load. I don't see why you think its dirty. Reflection is just another aspect of .NET

Preet Sangha
Not every developer that will touch the code understands reflection
tgeros
Dear or dear. Sorry - but shouldn't they learn it then?
Preet Sangha
For some people it's just a job - and that's fine with me.
tgeros