After deploying our huge distributed system to one of our clients we experience an unexpected error. During the investigation we replace the assembly causing the error with
You probably know this, but, variables are sometimes initialised differently in debug and release builds. E.g. I think variables are auto-init'd in VC6 debug builds, this can hide problems if you didn't initialise something. I also think debug arrays may use sentry bytes in an attempt to indicate overruns. This too can lead to different behaviour.
This probably isn't relevant for the original question, but for anyone running an application which uses
var isThisMyAssembly = System.Reflection.Assembly.GetCallingAssembly();
it's possible for that call to get inlined into a method in another assembly at runtime, and therefore to get unexpected output (as mentioned in the MSDN documentation).
To avoid this, you can either apply a MethodImplAttribute
to your method:
[MethodImpl(MethodImplOptions.NoInlining)]
void DoSomeThings()
{
var isThisMyAssembly = System.Reflection.Assembly.GetCallingAssembly();
//do stuff
}
or you can switch to using Assembly.GetExecutingAssembly()
instead.
You can try and turn off Optimize Code in the Build Settings. What is the actual error you are getting.
Another thing you can do is compile in release mode but enable the #Debug conditional. This will handle the case if your using Diagnostics.Debug and the code in there effects your application.
Debug.Assert(ImportantMethod());
I've seen timing which cause issues between Debug and Release build. Generally Debug build runs slower than Release build. You might want to check time critical section of your code.
In my case it was that my DLL consumer project (in VS) had x64 configuration, but the solution was in any CPU. For some reason when running the application this did not hook with my x64 DLL. I configured the application to a x64 explicitly platform and everything worked correctly.