Suppress debugger messagebox for unhandled exceptions in console app

[Jon Davis]

Is there an app.config setting I can add or a System.Diagnostic.Process
property I can tweak to cause someone else's CLR 2.0 console app to not show
a base CLR dialog box offering to debug the app when an unhandled exception
is reached? On production systems, I still get a dialog box with Debug /
Close buttons. IMO, this completely violates the fundamentals of what a
console app should be, but that's beside the point. I just want to suppress
these dialog boxes.

I'm trying to host multiple standalone EXEs as processes in a controlled
Windows Service and am already logging the stderrout messages to the Windows
Event Log. Adding a try/catch block to the Main method in the console apps
to prevent the debugger dialogue box isn't always doable when it's someone
else's codebase.

Jon

[Jon Davis]

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:Ow**************@TK2MSFTNGP04.phx.gbl...

Is there an app.config setting I can add or a System.Diagnostic.Process
property I can tweak to cause someone else's CLR 2.0 console app to not
show a base CLR dialog box offering to debug the app when an unhandled
exception is reached?

So while I have not been able to find a positive answer on this anywhere on
the web, the conclusion I suppose is 'yes and no'. No, there is no .config
file entry to "fix" this, and no there is no flag to be sent to the CLR to
fix it.

However, yes, this is perfectly fixable. One hour in bed and I woke up
*ding* realizing how simple it is.

Since the qualification of my own question was that the console app is
indeed a CLR 2.0 console app, that means that it is a fully adaptable
assembly, which in turn means that the assembly can be loaded as though it
were a DLL. 99% of the time, these assemblies will be invoked with static
void Main(string[] args) method. There is no reason, then, why I cannot
simply create a new EXE stub that dynamically loads the assembly in question
and calls its Main() method, wrapping that in a try...catch.

Jon

[Jon Davis]

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%2******************@TK2MSFTNGP06.phx.gbl...

Since the qualification of my own question was that the console app is
indeed a CLR 2.0 console app, that means that it is a fully adaptable
assembly, which in turn means that the assembly can be loaded as though it
were a DLL. 99% of the time, these assemblies will be invoked with static
void Main(string[] args) method. There is no reason, then, why I cannot
simply create a new EXE stub that dynamically loads the assembly in
question and calls its Main() method, wrapping that in a try...catch.

The problem here turns out that the application configuration settings get
loaded in the context of the calling process, not the target CLR EXE.

The System.Configuration namespace is pretty detailed, but the ability to
completely reset the loaded configuration for another CLR EXE that doesn't
know it's being "wrapped", that's something I'm finding difficulty tracking
down.

Jon

[Jon Davis]

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

The problem here turns out that the application configuration settings get
loaded in the context of the calling process, not the target CLR EXE.

The System.Configuration namespace is pretty detailed, but the ability to
completely reset the loaded configuration for another CLR EXE that doesn't
know it's being "wrapped", that's something I'm finding difficulty
tracking down.

Trying brute force. I have my small EXE stub being copied to a temp
directory, along with the target EXE's nearby config files, and name the
stub EXE the same as the target EXE, and execute the stub with the
environment current directory to be the target EXE.

Jon