How do I determine the build mode using reflection?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

My company is setting up a deployment process for implementing .NET Windows
applications. One of the standards we want the process to enforce is
verifying that the assembly is built in release mode. Is there a way to
check an assembly to determine if it was built in release mode? The
deployment application will not have access to source code, just the compiled
assembly, so I am assuming I will need to use reflection. However, I have
not found anything in the System.Reflection namespace that provides the build
mode. Any ideas?
 
The pre-compiler definitions are are only available at compile time.

Anyway, (using default project settings) there is no difference between
a Release and a Debug build since the Symbol Store information is
stored in a separate .pdb file.

So why exactly have you choosen to enfore this policy?

Jan
 
Jan said:
The pre-compiler definitions are are only available at compile time.

Anyway, (using default project settings) there is no difference between
a Release and a Debug build since the Symbol Store information is
stored in a separate .pdb file.
Click to expand...

With the default settings, Release is optimized and Debug isn't.
 
Brad said:
My company is setting up a deployment process for implementing .NET Windows
applications. One of the standards we want the process to enforce is
verifying that the assembly is built in release mode. Is there a way to
check an assembly to determine if it was built in release mode? The
deployment application will not have access to source code, just the compiled
assembly, so I am assuming I will need to use reflection. However, I have
not found anything in the System.Reflection namespace that provides the build
mode. Any ideas?
Click to expand...

Hi Brad, I know this is possible because I had to do it 2 or 3 years ago. My
memory is getting progressively worse these days, but I'm pretty sure I used
the DebuggableAttribute. Have a look at it, it allows you to check whether
the code is JIT optimised or not. I'm pretty sure that this attribute is
added to an assembly automagically on a debug build. So a wee bit of
reflection should give you the information you need.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
 
But do you know what optimizations those are? I've profiled debug and
release on a couple of applications and there's been no performance
gain but realease was smaller. So the optimatization is probably space
not speed.
 
You're totally right [assembly: Debuggable(true, true)] is set if it's
a debug build.
You learn something new everyday!

Jan
 
Jan said:
But do you know what optimizations those are? I've profiled debug and
release on a couple of applications and there's been no performance
gain but realease was smaller. So the optimatization is probably space
not speed.
Click to expand...

You probably weren't doing anything intensive enough for it to matter. Some
more complex C# apps I've worked on experience 500% performance increases
when run in release. Admittedly some of this is undoubtedly due to
configuration dependent execution.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
 
Back
Top