Debug Mode vs. Release Mode - IsJITOptimizerDisabled Property

Question

Hi everyone,

I just had a look at previous questions on topic, but I've got some strange results.

First of all, I followed and used the method that Scott Hanselman proposed in a old post in his blog: http://www.hanselman.com/blog/HowToProgrammaticallyDetectIfAnAssemblyIsCompiledInDebugOrReleaseMode.aspx

Thus, Using the IsJITOptimizerDisabled I'm supposed to check if a particular DLL has been compiled in release mode or in Debug mode.

The strange thing is that I just tried it, built a simple App that check that property and notify the assembly inspected is in debug or in release mode. Checked the results and everything it's ok against two dll I already compiled in both modes.

Then I passed that simple app to a colleague that confirm that in his workstation the results are as expected, the Debug dll show "Debug", the release show "Release" (those two dlls are contained in the same zip of the simple app).

But, when he tries to check those dlls with that simple app in another server (via mstsc) for both of the dll the simple app show "Debug" (even if opening the DLL with ILDASM everything seems fine and some specific methods contained inside a "#if DEBUG" region are not present in the Relase dll).

Now, I'm going mad, is there some reason behind this issue? Am I just too old to see what's going on ? Could be the reflection somehow dependant among the environment? Is there some Service pack that solved a similar known issue ?

Cheers,

Gianluca

Answer 1

The DebuggableAttribute is an attribute which is not compiled into the IL code contained in the executable assembly. It is inserted by the runtime when the assembly is loaded. The creation of the attribute might be affected by environment settings.

For example, a profiler being enabled on the system might have created environment variables or Registry settings that affect the debugging flags. A thread on the MSDN forums suggest to check for environment variables named COR_* or Registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework (and possibly HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework as well).

Answer 2

Using Assembly.LoadFrom() is not a very good idea in this specific case. Use fuslogvw.exe to find out why your program loaded the wrong assembly. GAC, probably.

Anyhoo, LoadFile() is called for here.