Geek Answers Handbook

Can I prevent the CLR from optimizing debug information?

I wrote an abstract base class for unit tests that sets up enough environment for our tests. The class provides some of the bits of the runtime environment as properties whose types differ by test (property types are type arguments specified in the inheritance class, specific testing).

This is good and good, except that a colleague noticed that he cannot view any class properties in the debugger. It turns out that the reason is that it did not have fields defined in its inheritance class, and the CLR optimized something, so the debugger could not display the properties. Is there any way to prevent this in the base class, or do I need to resort to telling everyone who needs to determine at least one field that is used somewhere during the tests?

Edit:

It seems like optimization / debugging settings should be the likely culprit. However, I create an application from Visual Studio in debug mode, I double-checked that all projects are configured to build debugging, and none of the projects in this solution have the optimization flag set.

Perhaps it would also be important to note that I am using MSTest and the Visual Studio test runner.

Edit 2:

From “cannot view properties” I mean when I evaluate a property in Quickwatch and get a red exclamation mark and the text “I cannot evaluate the expression” error. And so that you do not think that I am fully focused on my suspicions, adding an instance field that is initialized in the test initialization method makes the problem go away ...

Edit 3:

Checked build output. I notice that the compiler is called with these parameters:

/debug+
/debug:full
/optimize-
/define:DEBUG,TRACE

I should think that this will be enough to prevent this from happening, but you go there. :)

+7
source share
3 answers

, , Debug - . :

  • () - .
  • "" " " .

, , , .

+7

Dont forget the obvious

, arent . . - ; -)

+2

In my case, the project configuration was correct, but my code was the result of decompilation from ILSpy, and it had build attributes like the following:

[assembly: CompilationRelaxations(8)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)]
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Removing these attributes fixed the debugger ...

0
source

More articles:


All Articles