June 2004 - Posts

Determine if a .NET Assembly is Release or Debug

We recently got a bug report where a tester got a Debug.Assert failure in what I thought was a Release mode build. I went over to her machine, but found I couldn't tell from the binaries if it was a Release or a Debug build. ILDASM is no help, as Debug and Release are just build modes, and don't leave markers in the assemblies.

To differentiate between Release and Debug builds, I added the following to my AssemblyInfo.cs

// Compile a Debug or Release flag into the assembly.

#if DEBUG

[assembly: AssemblyDescription("Debug")]

#else

[assembly: AssemblyDescription("Release")]

#endif

 

This places Debug or Release in the file's metadata, where it can be seen under Properties | Version | Comments.
Posted 16 June 2004 03:30 PM by Ted_Graham | 7 comment(s)
Filed under: ,
ExecutionEngineException explained
 
Last week several of our developers, myself included, experienced repeatable crashes of our Windows Forms application with an ExecutionEngineException.  MSDN describes it as "The exception that is thrown when there is an internal error in the execution engine of the common language runtime.", which didn't help us to track it down.  The debugger was useless, as ExecutionEngineException cannot be caught and the callstack was pointing into a Application Block that hadn't changed. 
 
Our problem turned out to be old versions of some of our assemblies in a folder that was in the DEVPATH environment variable.  Our nAnt build uses the resgen tool, which requires setting the DEVPATH variable.  Unfortunately, DEVPATH breaks the normal .NET loading rules.  DEVPATH assemblies are bound to at runtime, ignoring the assembly version, and overriding the GAC.  (http://blogs.msdn.com/suzcook/archive/2003/08/15/57238.aspx)
 
Lessons learned:
  1. Don't use DEVPATH - See Suzanne Cook's linked blog above for all the reasons why
  2. One cause of ExecutionEngineException is mixing assemblies at runtime that weren't compiled together on the last compile.
  3. If only some developers or users are experiencing a problem, don't write it off as unreproducible.  Finding the difference that causes the problem will lead you to the solution.

 

Posted 07 June 2004 11:22 AM by Ted_Graham | no comments
Filed under:
More Posts