3

Is there any way that my code can tell the difference between "I am executing in normal process context" and "I have been executed from the Immediate Window of the Debugger"?

I have a library object which exposes a public property. When using the release version of that library, but debugging an application that has loaded the DLL containing that library, if I change the property from the Immediate Window (x.prop = true), I would like my property code to detect this and execute differently.

Is there a way to detect this?

For convenience sake, I would also like this to work when I am using the debug version of that library. So, I can't just check to see if there's a debugger attached, and branch from there.

Joe
  • 483
  • 1
  • 4
  • 7
  • 1
    While you wait for someone with an answer, try playing with the [StackTrace](http://msdn.microsoft.com/en-us/library/system.diagnostics.stacktrace(v=vs.100).aspx) class and see if you can tell from the call stack whither came the call. It may be obvious that it came from a debugger assembly. – HABO Aug 27 '12 at 01:21
  • http://stackoverflow.com/questions/2188201/is-there-a-way-to-detect-if-a-debugger-is-attached-to-a-process-from-c-sharp You could try this – Paul Farry Aug 27 '12 at 01:23
  • @Paul, thanks, but that system uses Debugger.IsAttached, which I specified can't work here, as this code would also run when I was debugging the library itself... – Joe Aug 27 '12 at 04:43
  • @Habo, thanks, I did check this out first. The Immediate Window is apparently very good at hooking right into the existing stack, because there's no mention of it in the stack. There's nothing in the stack except what would be there ordinarily. I was disappointed. – Joe Aug 27 '12 at 05:02
  • +1 good question, related http://stackoverflow.com/a/10918403/495455 - if there is no solution to this question, a workaround is to use overloaded methods to execute differently when called from the Immediate Window. – Jeremy Thompson Aug 27 '12 at 06:54
  • @Jeremy, am I right in parsing your suggestion as ""have an overloaded method which you never call from code, but you do call from the Immediate Window" ? It's a possible approach, but that would still make it public method, and I would not want consumers of my library to call that overload. At this point, I'm probably going to assume that what I want is not doable. VS is just too good at making the Immediate Window operate on my thread, in my process, in my context. Dang those guys. :-) – Joe Aug 27 '12 at 07:37

2 Answers2

2

One thing I've always noticed is that any calls from the Immediate Window contain at least one call originating from the following namespace:

Microsoft.VisualStudio.HostingProcess

So if you had, say:

public static string DumpStack()
{
    return new StackTrace().ToString();
}

You'd see something akin to:

   at ConsoleApplication1.Program.DumpStack()
   at ConsoleApplication1.Program.Main(String[] args)
   at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
   at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()
JerKimball
  • 16,584
  • 3
  • 43
  • 55
1

the only 1 thing to check, if the call is from the Immediate Window is to create OUTSIDE of your function one thread. That Thread sets a Boolean.

Normally, the immediate window is not able to use other threads, because they are frozen. Means, if your boolean doenst changed, then you are a immediate window.

I hope, that this is understandable.

Felix Wohlfarth
  • 11
  • 2