469,627 Members | 936 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,627 developers. It's quick & easy.

Suppress debugger messagebox for unhandled exceptions in console app

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
May 15 '07 #1
3 5024
"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

May 16 '07 #2

"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
May 18 '07 #3

"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
May 18 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by canhamdlc | last post: by
2 posts views Thread by Nak | last post: by
1 post views Thread by Chris Stiefeling | last post: by
3 posts views Thread by NickP | last post: by
5 posts views Thread by Jon Davis | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.