C# optimized code prevents debugging

[Zytan]

I have the simplified build ("show advanced build configurations"
turned off), so that pressing F5 runs in DEBUG mode with the
debugger. When an assertion fires, I find that I cannot 'watch' some
data, it explains that "Cannot evaluate expression because the code of
the current method is optimized". I know that I can go into Project-

>Properties->Build->"optimize code" and turn this off.

My question: WHY is the DEBUG build optimizing code? Shouldn't that
only occur for RELEASE builds? And, is my simplified build settings
("show advanced build configurations" turned off) causing this
"optimize code" to be set for both DEBUG and RELEASE, whereas maybe it
would only be set for RELEASE?

Zytan

[Jon Skeet [C# MVP]]

Zytan <zy**********@g mail.comwrote:

I have the simplified build ("show advanced build configurations"
turned off), so that pressing F5 runs in DEBUG mode with the
debugger. When an assertion fires, I find that I cannot 'watch' some
data, it explains that "Cannot evaluate expression because the code of
the current method is optimized". I know that I can go into Project-

Properties->Build->"optimize code" and turn this off.

My question: WHY is the DEBUG build optimizing code?

Because you've told it to, by the sounds of it. If you've got
optimisation turned on in the project properties (which it isn't by
default) then why would you expect it not to optimise?

Shouldn't that only occur for RELEASE builds? And, is my simplified
build settings ("show advanced build configurations" turned off)
causing this "optimize code" to be set for both DEBUG and RELEASE,
whereas maybe it would only be set for RELEASE?

Not sure what you mean - I haven't seen "simplified build settings"
before.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Zytan]

... If you've got

optimisation turned on in the project properties (which it isn't by
default) then why would you expect it not to optimise?

I would expect this to be one of those properties that affects ONLY
the release build, not the debug build:

http://blogs.msdn.com/lukeh/archive/...17/482045.aspx
"Project Properties don’t allow you to choose which build
configuration they apply to. Instead, the setting you provide is
applied to either both or just Release depending on the setting."

I would have assumed "optimize code' would apply to JUST the release.
I mean, why would you want DEBUG code to be optimized? Ever?

Thanks for your reply, Jon.

Zytan

[Zytan]

http://blogs.msdn.com/lukeh/archive/...17/482045.aspx

"Project Properties don’t allow you to choose which build
configuration they apply to. Instead, the setting you provide is
applied to either both or just Release depending on the setting."

(Note that this refers to the C# Express edition... please read the
whole article, it's interesting if you don't already know about it.)

Zytan

[JS]

I always assumed that this was because
System.Diagnost ics.Debug.Asser t() is optimized. I never suspected it
had anything to do with any build settings of your project. When I
hit an assertion, I just hit Shift-F11 to get out of the Assert()
method, and then I can look at values of properties.

[Jon Skeet [C# MVP]]

Zytan <zy**********@g mail.comwrote:

... If you've got
optimisation turned on in the project properties (which it isn't by
default) then why would you expect it not to optimise?

I would expect this to be one of those properties that affects ONLY
the release build, not the debug build:

http://blogs.msdn.com/lukeh/archive/...17/482045.aspx
"Project Properties don=3Ft allow you to choose which build
configuration they apply to. Instead, the setting you provide is
applied to either both or just Release depending on the setting."

Interesting. It's often the case that making things simpler for some
people makes them more complicated (and less predictable) for others :(

I would have assumed "optimize code' would apply to JUST the release.
I mean, why would you want DEBUG code to be optimized? Ever?

Because "Debug" is just an arbitrary label, I believe. There's nothing
really magical about Debug and Release as build configurations, as far
as I know. You can create your own, call them what you want and tweak
them however you want.

Disallowing certainly combinations based on the name would be quite odd
IMO as well as presenting some UI difficulties.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Zytan]

Interesting. It's often the case that making things simpler for some

people makes them more complicated (and less predictable) for others :(

Yes.

I would have assumed "optimize code' would apply to JUST the release.
I mean, why would you want DEBUG code to be optimized? Ever?

Because "Debug" is just an arbitrary label, I believe. There's nothing
really magical about Debug and Release as build configurations, as far
as I know. You can create your own, call them what you want and tweak
them however you want.

I understand. But, it appears that this 'simplified' project settings
for Express editions make clear decisions based on Release or Debug,
meaning that they are not just labels -- not in this context. The
settings specifically apply to one or both. It's too bad it doesn't
tell you which. :)

When I turn ON "show advanced build configurations" , it shows
"optimize code" ON for Release and OFF for Debug, which is what I
expect (although, I may be the author of those settings).

Disallowing certainly combinations based on the name would be quite odd
IMO as well as presenting some UI difficulties.

Yes, but, as the article states... this is what they desired. The
point being: for the beginner who comes into C# Express who just wants
to build Debug and Release and not worry -- that's who it's for. And
I've grown to like it because it's simple, but I dislike it because it
does things like optimizing code for Debug when I didn't want it to.

Zytan

[Zytan]

I always assumed that this was because

System.Diagnost ics.Debug.Asser t() is optimized. I never suspected it
had anything to do with any build settings of your project. When I
hit an assertion, I just hit Shift-F11 to get out of the Assert()
method, and then I can look at values of properties.

Nope, it's because the code is optimized by the compiler, and the
debugger doesn't know where the values are that you want to look at.
Run the same code with "optimize code", and you'll see everything you
want to see.

Zytan