Release vs. debug

[spif2001]

Hi I'm having a problem with the release version of my application. A debug version of the same code works without flaws, but the release version throws an unhandled exception. I have searched my code for "#if (DEBUG) ... #endif"'s and "[conditional (DEBUG)]" functions and made sure that nothing vital lies within such areas (nothing there now but some WriteLine()s :)). Does anyone know of other differences between release and debug that could cause one but not the other to fail?

[Andy M]

You create a new project configuration that contains debug information but without the conditional DEBUG Conditional Compilation Constant, then you can at least put down breakpoints and step through the code to see what might be causing the problem.

[spif2001]

That didn't seem to make much difference - it still runs in debug without the DEBUG constant. But I discovered another really weird issue. As explained before I get an unhandled exception when I execute the release .exe file, but if I run the the application in release mode inside Visual Studio(VS) I don't get the exception. :confused: It seems that somehow VS has an influence on the release runtime. Also a fellow coworker experienced the same problem with another application, but with the debug .exe file. Does VS set up some special runtime environment that prevents unhandled exceptions?

[Dave Kreskowiak]

You might want to post what the exact exception was. RageInTheMachine9532 "...a pungent, gastly, stinky piece of cheese!" -- The Roaming Gnome

[spif2001]

It is a TypeInitializationException with the inner exception NullReferenceException - and why it is thrown only in the release version run outside VS is my big mystery. If I run the debug .exe file outside VS it doesn't throw anything.

[Heath Stewart]

Question: if you have a multi-project solution, did you add project references or assembly references? If you use assembly references (for projects in your solution), that can be a big problem since your release build will use assemblies from your debug build (or vice versa). If you added a new type and did a release build, this type would not be in the debug build of your assembly. So, remove your assembly references for projects in your solution. Then re-add them by right-clicking on your project, select Add Reference, then click on the Projects tab and select the right projects. This makes sure that everything is kept in sync and sets up build dependencies as well. When you run the application, everything should work fine. If you maintain a build directory for other developers, make sure that you copy all of the assemblies from the same build configuration into that build directory. We have a very large solution (I have about 60 projects in mine, being the build master), many of which are late-bound. Using these guidelines it's pretty easy to make sure everything is correct. Also make sure that if you have late-bound assemblies (like for a plug-in style application) that you either keep the assembly version the same or update your app's .config file using assembly version redirection. You can find more about that by reading Redirecting Assembly Versions[^] in the .NET Framework SDK. We also do this for ours so we don't have to re-deploy every assembly with updates to our application.

Microsoft MVP, Visual C# My Articles

[spif2001]

Thank you for the reply, but alas to no avail - all my references are added as you describe above. The world of VS is a cruel place ;)

[spif2001]

Heureka! - the bug has been found. It was a Singleton issue. I had a Singleton class like the following: private static readonly IOServiceAgent instance = new IOServiceAgent(); private IOServiceAgent(){} public static IOServiceAgent Instance { get { return instance; } } Changed it to the following: private static IOServiceAgent instance; private IOServiceAgent(){} public static IOServiceAgent Instance { get { if(instance == null) { instance = new IOServiceAgent(); } return instance; } } Somehow the first solution failed even though the property wasn't called prior to the exception throw. Anyway thanks for the replys -spif2001