The Optimize flag is set to true for the Release build configurations
and set to false for Debug build configurations. *hmm* It could be that
a Debug binary was released in error, but that's just a wild guess.
How did you come across this? Does the non-optimized debug assembly
cause problems?
On 2016-03-07 08:41, Pallier, Manuel / BEKO Graz wrote:
I've used the RedGate .NET Reflector, but the free ILSpy should show
it too.
------------------------------------------------------------------------
*Von:* Dominik Psenner [dpsen...@gmail.com]
*Gesendet:* Freitag, 4. März 2016 16:36
*An:* Log4NET Dev
*Betreff:* Re: 'DisableOptimizations' flag present in release builds
Hi Manuel,
I've tried but could not find the DisableOptimizations attribute.
Where did you see it?
Cheers,
Dominik
On 2016-03-03 16:06, Pallier, Manuel / BEKO Graz wrote:
Hi,
I just noticed the following attribute in the log4net 1.2.15 release
build:
[assembly:
Debuggable(DebuggableAttribute.DebuggingModes.DisableOptimizations |
DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
Usually a .NET assembly build with optimizations for release has only
one flag in this attribute:
[assembly:
Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
The flag „DisableOptimizations“ seems to indicate that the assembly
was build without compiler optimizations. Is this by design?
Version 1.2.13 didn’t have a Debuggable attribute at all. It seems
like 1.2.14 introduced it. From a quick look over the issues resolved
in 1.2.14 it might be related to
https://issues.apache.org/jira/browse/LOG4NET-456
