43

This is the function:

public void Init(System.Type Type) {
    this.Type = Type;
    BuildFieldAttributes();
    BuildDataColumns(FieldAttributes);
}

I've set a breakpoint on the first line (this.Type = Type) and I want to break when Type.FullName == "Malt.Organisation" so that's what I've entered in as the condition.

However the following error is displayed when the line is hit:

The condition for a breakpoint failed to execute. The condition was 'Type.FullName == "Malt.Organisation"'. The error returned was 'Inspecting the state of an object in the debuggee of type System.Type is not supported in this context.'

What (obvious) thing am I doing wrong?

PS. A workaround is to add this to the code:

if (Type.FullName == "Malt.Organisation") System.Diagnostics.Debugger.Break();
Wai Ha Lee
  • 8,598
  • 83
  • 57
  • 92
Rob Nicholson
  • 1,943
  • 5
  • 22
  • 37
  • Might not be relevant, but are you passing a [`RunTimeType` or a `Type`](http://stackoverflow.com/q/5737840/1364007) into your method? – Wai Ha Lee Aug 28 '15 at 17:40
  • 1
    The debugger is pretty explicit about it: "we don't support that yet". Not in VS2015 either, it ought to have a better shot at it thanks to Roslyn. If it ever will is a question you can't get answered here, you'd have to ask Microsoft. They are not apt to make promises. – Hans Passant Aug 28 '15 at 17:44
  • 1
    I strongly discourage you from using Type as a variable name or Property name. This will inevitably lead to conflicts because your variable is also the name of a well-known type. Does it work if you rename Type to type and/or theType? – stephen.vakil Aug 28 '15 at 18:41
  • Still happen in VS 2017 community edition. Managed-compatibility-mode is not really an option if you want the latest debugging features. – Paulustrious Jul 31 '17 at 17:05
  • 4
    @HansPassant: "The debugger is pretty explicit about it" - I disagree, because it is unclear what "that" is. Is there anything special about `System.Type` as a class with members? Is there an arbitrary list of types that can't be inspected for some reason? And what is "this context", anyway? In what context *is* inspecting the state of an object of type `System.Type` supported? As such, the message just says "Something is wrong.", but it gives no hint about *what* that something might be. – O. R. Mapper Sep 29 '17 at 07:44
  • 1
    @stephen.vakil: Not that I would say the possibility for confusion is not there, but Microsoft does not seem to share your concerns: [`System.Web.UI.WebControls.BaseCompareValidator.Type`](https://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.basecomparevalidator.type(v=vs.110).aspx), [`System.Linq.Expressions.Expression.Type`](https://msdn.microsoft.com/en-us/library/system.linq.expressions.expression.type(v=vs.110).aspx), [`System.Drawing.Imaging.PropertyItem.Type`](https://msdn.microsoft.com/en-us/library/system.drawing.imaging.propertyitem.type(v=vs.110).aspx). – O. R. Mapper Sep 29 '17 at 07:51
  • "We don't support that yet" is unacceptable. I've been doing that for **MONTHS** if not **YEARS**, even in VS2017, until recently, and now all of a sudden that "feature" has been disabled or intentionally broken. – mwpowellhtx Mar 05 '19 at 17:42
  • I might add, the problem here is not just one of naming conventions, but is one of the debugger supporting expressions, lambdas, etc. That support has been in there for a while now, at least until the recent breakage. – mwpowellhtx Mar 05 '19 at 17:43

5 Answers5

56

⚠ Heads up, seems this is no longer available since Visual Studio 2022.

In my case I was using Visual Studio 2013, NUnit 2.6.4, and attaching a debugger to a unit test session, and I was getting a similar message:

The condition for a breakpoint failed to execute. The condition was 'type.Name.Contains("FooBar")'. The error returned was 'Inspecting the state of an object in the debuggee of type System.Type is not supported in this context.'. Click OK to stop at this breakpoint.

This was caused by a missing feature in the new debug engine Microsoft had introduced, apparently. Following instructions from this msdn blogpost I got things to work. The instructions boil down to:

  1. From the "Tools" menu open "Options"
  2. On the left hand side pick "Debugging", "General"
  3. Scroll all the way down to check "Use Managed Compatibility Mode"

This should switch to the legacy debug engine, which in my case allowed for expressions on Type in break point conditions. Note that you do need to restart your app or debugging session, obviously.

Disclaimer: I have no idea what other effects checking this option had. Personally, I turned it back off when I was done with the task that required it...

Jeroen
  • 60,696
  • 40
  • 206
  • 339
  • 2
    This worked for me as well. There was definitely a heavy performance hit with my breakpoint. I think your suggestion to turn the setting off afterwards is wise. – yourbuddypal Jun 01 '16 at 17:05
  • 2
    Had a similar problem with VS2015 Update 2: a breakpoint with condition `pi.Name == "whatever"` (where `pi` is of type `System.Reflection.PropertyInfo`) throws up a dialog `Inspecting the state of an object in the debuggee of type System.Reflection.PropertyInfo is not supported in this context.` Forcing Managed Compatibility Mode for the debugger now allows the breakpoint to be hit as expected. How long will it take for MS to get their "new" debugger to feature-completeness with the "old" one? – Ian Kemp Jun 22 '16 at 13:13
  • 1
    A little bit about the ramifications of turning this on: https://blogs.msdn.microsoft.com/devops/2013/10/16/switching-to-managed-compatibility-mode-in-visual-studio-2013/ (TLDR: if you have "Use managed compatability mode" on, you can't edit code while in break mode) – derekantrican Jan 24 '19 at 22:29
  • 2
    The option _Use Managed Compatibility Mode_ helped me (+1) but this option disabled the _Diagnostic Tool_ window. This can be a reason to turn off the mode after debugging is completed. – Fenix Feb 10 '22 at 22:44
  • 1
    This option does not appear to exist in VS2022 (at least, Professional 64-bit edition). – qJake May 09 '22 at 15:46
  • 1
    Indeed, it seems to be gone. Will add that to the answer. – Jeroen May 09 '22 at 17:52
4

You say that Type.FullName == "Malt.Organisation" causes it to break, have you tried this.Type.FullName == "Malt.Organisation"?

Another possibility, does the debugger think you are trying to invoke a static method with having the variable named Type like its class name? Does renaming the Type variable to something else fix it?

Daniel Stone
  • 267
  • 3
  • 10
4

I ran into this but when testing for IsInterface in a Web Application. Instead of enabling extra features in the debugger, I simply cheated.

bool blnIsInterface = tType.IsInterface;

//Insert breakpoint here...
if(blnIsInterface)
{
    ...
}

So in your case your could do something like

public void Init(System.Type Type) {
    bool blnBreak = Type.FullName == "Malt.Organisation";
    //insert breakpoint of blnBreak == true
    this.Type = Type;
    BuildFieldAttributes();
    BuildDataColumns(FieldAttributes);
}

It's a bit cumbersome but at least you won't have to worry about performance hits and enabling Native code debugging doesn't seem to be an option in Web Applications.

Wes Hanney
  • 61
  • 2
1

I'm not sure about "Use Managed Compatibility Mode" solution described here - did not help me, but in my own case Project > Properties > Debug > Enable Native code debugging - must be unchecked.

Why - no clue currently.

Was using .net 4.5, vs2015, console application.

TarmoPikaro
  • 4,723
  • 2
  • 50
  • 62
1

That worked for me, give a shot:

var name = Type.FullName;
if (name == "Malt.Organisation") System.Diagnostics.Debugger.Break();
ddagsan
  • 1,786
  • 18
  • 21