What differs when Debug build is ran with debugging and without debugging?

I used to believe that if we got a Debug build it didn't really matter whether:

1. We ran it.
2. Or we debugged it.

everything would be the same.

However recently I ran into 2 different problems, where its clear that something is different when the code is just run, or when it is debugged, even if version of code开发者_如何学C is supposedly the same. (namely Fluent NHibernate cannot load MySql.Data from GAC in debug mode of a test and Npgsql - Specified method is not supported)

I am wondering what is that difference between those two in .NET 4.0? Understanding whats different could probably help me solve the issues I am having because I'll at least know where to look for possible causes of bugs in those different cases. I don't understand it when I run unit tests its all green, but when I try to debug them I get various exceptions thrown..

The weapon of choice for assembly resolution problems is fuslogvw.exe, it shows you where it looked for an assembly and what configuration is being used to tell the CLR where to find the assembly.

There is a secondary failure mode with the kind of assemblies you are having trouble with. These dbase providers are often managed wrappers that rely on unmanaged DLLs to get the job done. Windows must be able to find those DLLs. That tends to fail if they are not copied to a directory that's on the PATH or copied into the same folder as the main EXE. Carefully read the deployment instructions for these wrappers.

When debugging the timing of the code will be slightly different, more so if you sit inside functions too long. So if the code is time sensitive, you could run into weird errors. That's about all I can think of.

The difference is that when the debugger is attached, it can stop when exceptions are thrown that would otherwise be caught.

The options "Break when exceptions cross AppDomain or managed/native boundaries (Managed only)" and "Enable Just My Code" in Tools/Options/Debugging, and the options in Debug/Exceptions... will determine on what exceptions your debugger will break on when thrown.

There are a few issues to be wary of.

1) As codeninja says, the order of operations may be different if you break the code.

2) Files may be in different locations, and paths may resolve differently. This is very important when you have dynamically loaded resources, or where DLL's are built and copied to a plug in's directory. Under debug you can accidently load the wrong one.

3) Observing variables in the debugger can cause an evaluation. Imagine a property which stupidly incremented its backing field and then returned the incremented value.