Prevent JIT inlining

[Brian Keating]

Hello there,
I'm having a slight problem in that my JIT compiler is getting an exception
and I really don't know how to stop it.

Let me expain what's happening with the help of this simple test program.

[STAThread]
[MethodImpl(Meth odImplOptions.N oInlining)]
static void Main()
{
try
{
MessageBox.Show ("Start");
Application.Run (new Form1());
}
catch (Exception ex)
{
MessageBox.Show (ex.ToString()) ;
bfa.Diagnostics .Trace.WriteErr orWithMessageBo x(ex);
}
}


I put in a try/catch around my Main entry point.
My catch tries to log the exception with a utility in another library lets
call it DiagnosticLib.

No this is fine except if my DiagnosticLib is no on the target machine.

Ok if it's not there then i except big poblems trying to use it anyway
granted... but
I'm not even getting this far.. I don't see any ot the exception boxes i
would expect first,

I can only assume that the JIT has beat me to it?
I tried to stop inlining with [MethodImpl(Meth odImplOptions.N oInlining)] but
still no luck.

This one had me beat,
anyone any ideas?

thanks in advance
Brian Keating

[Marcus Andren]

Re: Prevent JIT inlining

On Tue, 31 May 2005 01:52:13 -0700, Brian Keating wrote:
[color=blue]
> try
> {
> MessageBox.Show ("Start");
> Application.Run (new Form1());
> }
> catch[/color]

This is incorrect. Application.Run won't through any exceptions. Instead
you should use the eventhandler Application.Thr eadException.

public static void Main()
{
Application.Thr eadException += new
System.Threadin g.ThreadExcepti onEventHandler( ErrorHandler);
Application.Run (new MainForm());
}

public static void ErrorHandler(ob ject sender,
System.Threadin g.ThreadExcepti onEventArgs ex)
{
MessageBox.Show (ex.Exception.T oString());
}

--
Marcus Andrén

[Brian Keating]

Re: Prevent JIT inlining

Hi Marcus,

Thanks for trying to help, as i stated this is a "test" program,
Wasn't really asking about exception handling as such and I got a solution
using reflection at any road.

Not to go flogging a dead horse but If you've a windows forms application
you need catch all unhandled exceptions with more than just the
Application.Thr eadException that you mention.

My application (My test app which had alot obmitted for brevity) has the
Application.Thr eadException
also has
AppDomain.Curre ntDomain.Unhand ledException which catches unhandled
exceptions in the clr
Also a try catch is needed around my Main,

Let me explain why try catch is needed:
This is because my main may do more than just Application.Run (new MyForm1());
I.e. what happens if an exception happens before the Application.Run is
executed,
(ok my test app didn't do more than a MessageBox.Show (",) but..... )
Even if it starts to execute the Application.Run line of code the MyForm1
constructor could throw an exception before the Application.Run (...) part of
the statement ever executes.

Once again thanks for your time however
regards
Brian.


"Marcus Andren" wrote:
[color=blue]
> On Tue, 31 May 2005 01:52:13 -0700, Brian Keating wrote:
>[color=green]
> > try
> > {
> > MessageBox.Show ("Start");
> > Application.Run (new Form1());
> > }
> > catch[/color]
>
> This is incorrect. Application.Run won't through any exceptions. Instead
> you should use the eventhandler Application.Thr eadException.
>
> public static void Main()
> {
> Application.Thr eadException += new
> System.Threadin g.ThreadExcepti onEventHandler( ErrorHandler);
> Application.Run (new MainForm());
> }
>
> public static void ErrorHandler(ob ject sender,
> System.Threadin g.ThreadExcepti onEventArgs ex)
> {
> MessageBox.Show (ex.Exception.T oString());
> }
>
> --
> Marcus Andrén
>[/color]

[Willy Denoyette [MVP]]

Re: Prevent JIT inlining


"Brian Keating" <BrianKeating@d iscussions.micr osoft.com> wrote in message
news:AAB57321-CB65-42D8-8500-CC72AE531C50@mi crosoft.com...[color=blue]
> Hi Marcus,
>
> Thanks for trying to help, as i stated this is a "test" program,
> Wasn't really asking about exception handling as such and I got a solution
> using reflection at any road.
>
> Not to go flogging a dead horse but If you've a windows forms application
> you need catch all unhandled exceptions with more than just the
> Application.Thr eadException that you mention.
>
> My application (My test app which had alot obmitted for brevity) has the
> Application.Thr eadException
> also has
> AppDomain.Curre ntDomain.Unhand ledException which catches unhandled
> exceptions in the clr
> Also a try catch is needed around my Main,
>
> Let me explain why try catch is needed:
> This is because my main may do more than just Application.Run (new
> MyForm1());
> I.e. what happens if an exception happens before the Application.Run is
> executed,
> (ok my test app didn't do more than a MessageBox.Show (",) but..... )
> Even if it starts to execute the Application.Run line of code the MyForm1
> constructor could throw an exception before the Application.Run (...) part
> of
> the statement ever executes.
>
> Once again thanks for your time however
> regards
> Brian.
>
>[/color]

The problem is that when the "main" method is JIT compiled the assembly and
class loader will try to load the external assembly containing the
WriteErrorWithM essageBox method, if the library cannot be found there is no
way for the JIT to compile the main method.
Inlining/no-inlining has nothing to do with this, "main" is never inlined
b.t.w.

Willy.

[Brian Keating]

Re: Prevent JIT inlining

Hi Willy,

Thanks for your input, your correct of course, JIT inlining was totally the
wrong heading and nothing to do with the problem i was seeing.

As i said i managed to do it with reflection in the end but this is not
really a good solution for me
(mainly because MyAssembly now has a MyApplication class which I call
MyApplication.R un(new Form1());
so i don't just have exception handler to worry about loading with
reflection..

At the moment I've got to live with the fact that if my assembly is missing
then there is nothing i can do, the default unhandled exception box will
appear and i've no way of informing the user that MyAssembly.x.x. x.x is
missing.

Don't know if there is a way to get this information to the user that
assembly xyz version x.x.x.x is not present.

I can live with a system message box telling me - ok big problems
MyAssembly.x.x. x.x is missing

Anything else i can assume that it loaded MyAssembly and all exceptions will
be handled by MyAssembly.

Don't know if you've any ideas on this one.
but thanks for your help so far.

regds
Brian

[color=blue]
>
> "Brian Keating" <BrianKeating@d iscussions.micr osoft.com> wrote in message
> news:AAB57321-CB65-42D8-8500-CC72AE531C50@mi crosoft.com...[color=green]
> > Hi Marcus,
> >
> > Thanks for trying to help, as i stated this is a "test" program,
> > Wasn't really asking about exception handling as such and I got a solution
> > using reflection at any road.
> >
> > Not to go flogging a dead horse but If you've a windows forms application
> > you need catch all unhandled exceptions with more than just the
> > Application.Thr eadException that you mention.
> >
> > My application (My test app which had alot obmitted for brevity) has the
> > Application.Thr eadException
> > also has
> > AppDomain.Curre ntDomain.Unhand ledException which catches unhandled
> > exceptions in the clr
> > Also a try catch is needed around my Main,
> >
> > Let me explain why try catch is needed:
> > This is because my main may do more than just Application.Run (new
> > MyForm1());
> > I.e. what happens if an exception happens before the Application.Run is
> > executed,
> > (ok my test app didn't do more than a MessageBox.Show (",) but..... )
> > Even if it starts to execute the Application.Run line of code the MyForm1
> > constructor could throw an exception before the Application.Run (...) part
> > of
> > the statement ever executes.
> >
> > Once again thanks for your time however
> > regards
> > Brian.
> >
> >[/color]
>
> The problem is that when the "main" method is JIT compiled the assembly and
> class loader will try to load the external assembly containing the
> WriteErrorWithM essageBox method, if the library cannot be found there is no
> way for the JIT to compile the main method.
> Inlining/no-inlining has nothing to do with this, "main" is never inlined
> b.t.w.
>
> Willy.
>
>
>
>[/color]