views:

147

answers:

3

I have a function that I want to be sure is compiled JIT (i.e. right before it's called). Are there attributes or assembly settings that will ensure this? If not, then how can I guarantee that a function is compiled JIT?

Thanks!

EDIT:

I want to do this to prevent my application from crashing due to a missing referenced assembly. If my function is compiled JIT, I can wrap the function call that references the missing assembly in a try...catch block and gracefully handle the situation.

It is my understanding that there could be times when whole classes (or even the whole application) could be Jitted - this would cause an error I couldn't possibly catch.

A: 

I may be answering the wrong question, but it looks like you mainly want to be able to intercept assembly load failures (whole classes being JITted defeat the try/catch guards around the calls but that's a side effect of using explicit guards around method calls).

If you want to catch assembly resolution woes, instead of specifying a try/catch around every possible call, you could just listen to the global AssemblyResolve event and respond to the assembly loading failures (we're talking about .Net assemblies here, native dll's load failures would have to be tracked with a different mechanism).

static void Main()
{
 AppDomain.CurrentDomain.AssemblyResolve += OnResolveFailure;
 //...
}

static Assembly OnResolveFailure(object sender, ResolveEventArgs args)
{
 //Do something here...
}

The downside of this is you can't do much, except looking for the assembly somewhere else (or logging the error). Specific and graceful logic when a resolution fails is not provided with this way of catching load failures.

Yann Schwartz
I've tried something similar too, but, as you've stated, I can't do much after that other than log the error. Being able to wrap a function call in a try...catch (which I'm doing now, and it works terrifically) without having to worry that the mechanism I'm relying on (JIT compilation) will fail is my goal. Thanks!!
Pwninstein
+2  A: 

If I read this correctly, you are worried about errors occurring when a class/method is first compiled. This requires awareness of the boundaries. It is obtainable with an extra layer.

If something is 'wrong with SuspectType (ie a required assembly not loading), the try/catch in the following is of no use because the Jitting of Scenario1() itself will fail.

void Scenario1()
{
   try
   {
     var x = new SuspectType();
     ...
   }
   catch (..) { ... }    
}

It could be rewritten as

void Scenario1a()
{
   try
   {
      Scenario1b();
   }
   catch (..) { ... }    

}

void Scenario1b()
{
     var x = new SuspectType();
     ...
}

But, per Jon Skeet's comment, I'm not sure if this holds for the CFx.

Henk Holterman
A: 

Is this something that your app needs to be able to resolve on it's own, or are you debugging some kind of assembly load problem right now?

If the latter, have a look at the fusion log. This is log that is generated by the subsystem that probes for and loads assemblies at run time.

Here's an article: http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx

JMarsch