When release dlls don't work but debug dlls do

Question

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

Answer 1

I had a similar problem. My situation like this: I defined some reflection functions in a class library A. Then I defined a WPF user control library B, which uses the functions from library A. Then I coded an application which uses the user control from library B and functions in library A. When I used the debug version of library B, it works fine. But when I used the release version of library B, the reflection functions did not work. I also defined other functions in library A. It seems that only reflection functions are causing trouble. I can not figure out the reason. Finally, I gave up and moved the reflection functions from library A to library B. And it worked.

Answer 2

Did you solved your problem?
I'm having the same issue as you.
If I compile the dll in debug, all works fine.
If I compille in release I get a null reference exception.
But if I include some lines like the above one in some methods call, the exception is gone even in release mode:
System.Diagnostics.EventLog.WriteEntry("blablabla", "blablabla")

Hope that helps you.

Answer 3

Make sure that the Application is building under the correct Platform Target. This can be an issue especially when it comes to providing or consuming DLLs. Look under "Project->Properties" and select the "Build" tab. The Platform target option will allow you to select between Any CPU (default), x86 or x64.

Answer 4

I had a problem at one point with finalizers going off sooner than expected, because I didn't fully understand the interplay between finalizers, the garbage collector, and when a local object is considered collectible (hint: it's not at the closing curly brace of the block). If your code uses finalizers, you may wish to look into GC.KeepAlive(). In the following block:

void MyFunction() 
{ 
  Foo f = new Foo();
  SomeFunction(f.SomeProp);
}

f becomes eligible for finalization before SomeFunction() even runs! If the finalizer does something like dispose whatever SomeProp hands out, you could get into trouble. Adding a call to GC.KeepAlive(f) after the call to SomeFunction ensures that f isn't eligible for finalization until after the call to KeepAlive().

Edit: After all that, I forgot to point out that this problem was much more pronounced when running in Release mode. I don't know if the Debug build puts implicit KeepAlives for locals at the end of the function for the debugger's benefit, or if the garbage collection is simply less aggressive, or what, but Release mode exacerbated this problem greatly in my case.

Answer 5

Had the same issue with a C# DLL containing a WCF client provided for multiple client applications.

Found out there was a method in the C# client library accessing the StackTrace for logging purposes, which happens to be different when compiled in debug.

StackTrace stackTrace = new StackTrace();
MethodBase methodBase = stackTrace.GetFrame(2).GetMethod();

GetFrame(2) didn't existed in release. More info about that can be found here: StackTrace class methods not working in release mode

Funny thing is a VB.NET client was affected while in another C#.NET client it worked properly.

Hope it helps.

Answer 6

It might be some sort of race condition you have, if you're not working in single-threaded code. For example, if some part of your program needs to perform some actions before other parts can access it, it might fail in release mode simply because the code is accessed too early. We once had a similar problem with some code for mobile phones which ran fine in the emulator but on the phone which was slower, the sitution was not the same at all.