You're looking for '__CLR_VER' - check http://msdn2.microsoft.com/en-us/library/b0084kay.aspx. I don't believe you can change the framework you're linking to without switching compilers though.

> Yes, the values in the array are retrieved from a database lookup, and they can only be inserted in the database if one of the values is true. I'd be inclined to add a throw or at least an assertion for an expected behaviour like that, it's not the same as it being impossible. I only ever saw the compiler bug you linked once and it was in a pretty munged loop (nested STL adaptors, Managed code), I'm surprised something so simple could reproduce it. Have you utterly verified that index 0 in that case was true in Release as well? Shame the MSIL output may not tell the whole story :(

Have you verified that it's impossible for all 5 values to be false? Because that loop will run off because they all are. This is likely the case as: a) it's fixed by your explicit check. b) this is classic of discrepancies with uninitialised data in Debug & Release. Specifically, the debug code will safely terminate hitting malloc guard bytes/uninitialised flood pattern which it will see as 'true' whereas Release will spin off the end until it hits a non-zero byte (which will match an invalid index) or segfaults. When you see different control paths in debug & release it's normally to do with the flood patterns the former uses.