Reputation: 1277
the .Net property Debugger.IsAttached can be used at runtime to detect if a debugger is attached or not. That means this property can be used for having a different behavior when the debugger is attached. I can easily come up with examples that show why not to use this property (because the program will be hard to debug) but I have a hard time to find an example in which it seems legitimate to use it.
Do you have use-cases where Debugger.IsAttached is the sensible choice to use?
Upvotes: 5
Views: 313
Reputation: 1060
A good usecase is using it on the startup of your application to start some services only if you have a debugger attached.
My case is using the Hangfire Dashboard.
Hangfire comes with a dashboard but you have to set it up on application startup, the dashboard is realtime and consumes resources that i don't need it to on a production environment as noone will need to see it only me when i am debugging. So i set the condition to fire up the dashboard only when i am in debug mode so i can see running jobs and their status and why they failed.
Upvotes: 2
Reputation: 117301
I personally find it useful for logging. When debugger is attached then logging goes to the console window if not it goes though the Nlog setup which actually writes the logs out as json.
if (!Debugger.IsAttached)
logging.AddNLog(NLogAspNetCoreOptions.Default);
else
logging.AddConsole();
Upvotes: 4
Reputation: 157116
You can use that property in some scenarios to halt a service at a specific point when the debugger is attached to a remote server for example. Then that check would be accompanied by Debugger.Break
.
Another use case might be some additional logging (containing sensitive or extensive logging) that is written to the console.
Upvotes: 4