[ACCEPTED]-When release dlls don't work but debug dlls do-debugging

For causes... well, some hint of the symptom 16 would help. One possibility is that you 15 have code to a method like Debug.WriteLine that has side 14 effects (i.e. makes it work). Calls to methods 13 marked with [Conditional(...)] are not compiled unless you 12 have the right symbols defined - so anything 11 marked [Conditional("DEBUG")] will be silently dropped.

It could 10 also be a compiler bug, but that is a bit 9 unlikely (but not impossible).

What is the 8 symptom? How does it break?

As an example 7 of the above:

    static string Bar { get; set; }
    static void Main()
    {
        Bar = "I'm broken";
        Debug.WriteLine(Foo());
        Console.WriteLine(Bar);
    }
    // note Foo only called in DEBUG builds
    static string Foo()
    {
        Bar = "I'm working";
        return "mwahahah";
    }

Compiled in DEBUG mode it prints 6 "I'm working"; compiled in RELEASE mode 5 it prints "I'm broken". Does this sound 4 similar? Check you aren't calling any debug 3 methods directly with things that have side-effects. In 2 most cases, you can fix by indirection:

string foo = Foo();
Debug.WriteLine(foo);

Now 1 it gets called in either mode.

You can try and turn off Optimize Code in 6 the Build Settings. What is the actual error 5 you are getting.

Another thing you can do 4 is compile in release mode but enable the 3 #Debug conditional. This will handle the 2 case if your using Diagnostics.Debug and 1 the code in there effects your application.

Have you tried including the debug files? (the 8 pdbs)

If you co go your project settings 7 and then the compile 'tab' select your release 6 build in the dropdown near the top, then 5 choose advanced compile options near the 4 bottom, make sure to set it to create FULL 3 debug information, then redeploy, you should 2 now get more detailed information about 1 the reason for the crash.

I've seen timing which cause issues between 4 Debug and Release build. Generally Debug 3 build runs slower than Release build. You 2 might want to check time critical section 1 of your code.

Debug.Assert(ImportantMethod());

0

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

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

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

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

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

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

Hope it helps.

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

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

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

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

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

First of all sorry about my English. I know 8 this post is old but I have just the same 7 problem, and I realize that in debug mode 6 the build is made for 32 bit OS, and the release 5 mode is for 64 bit by default. This make the DLL's 4 made for 32 bit doesn't work in release. If 3 you go to Project properties -> build you 2 can choose the architecture you want. This 1 works for me.

You probably know this, but, variables are 8 sometimes initialised differently in debug 7 and release builds. E.g. I think variables 6 are auto-init'd in VC6 debug builds, this 5 can hide problems if you didn't initialise 4 something. I also think debug arrays may 3 use sentry bytes in an attempt to indicate 2 overruns. This too can lead to different 1 behaviour.

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

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

Hope 1 that helps you.

In my case it was that my DLL consumer project 6 (in VS) had x64 configuration, but the solution 5 was in any CPU. For some reason when running 4 the application this did not hook with my 3 x64 DLL. I configured the application to 2 a x64 explicitly platform and everything 1 worked correctly.

This probably isn't relevant for the original 7 question, but for anyone running an application 6 which uses

var isThisMyAssembly = System.Reflection.Assembly.GetCallingAssembly();

it's possible for that call to 5 get inlined into a method in another assembly 4 at runtime, and therefore to get unexpected 3 output (as mentioned in the MSDN documentation).

To avoid this, you 2 can either apply a MethodImplAttribute to your method:

[MethodImpl(MethodImplOptions.NoInlining)]
void DoSomeThings()
{
    var isThisMyAssembly = System.Reflection.Assembly.GetCallingAssembly();
    //do stuff
}

or you 1 can switch to using Assembly.GetExecutingAssembly() instead.

It might be any reason, but what comes in 3 mind is either

1. You might have written an logic which is under debug_enabled flag, which is accessed when debug_enabled flag is not enabled(i.e release mode). For example a pointer created under debug_enabled flagged if condition but accessed out of the area in release mode.
2. When I faced the same issue, what resolved is I was not returning anything while a function expected a return value, while I was returning only during negative scenarios in that function. I got to know that by adding loggers and when i fixed that, it automatically started to run fine.

Only doubt is why this issue 2 didn't happen in debug dll whereas in release 1 it gave an error.

Anyways hope it helps!