I work on an application in C# 4.0 (VS2010), and I have a very strange situation. A bug is reported to me from all the team and I always fail to reproduce it, till one of the other developers told me to double-click the executable and follow the bug’s scenario instead of launching it from VS2010.
After some research, I found that most of the comments on this problem are regarding uninitialized heap memory and the like, but in a C++ context. I know that C# produces an error rather than a warning if a variable is left uninitialized, so this is not the problem, most probably.
Both builds are the same on my machine and the users’, and I now know that pressing F5 (Start with debugging) doesn’t produce the problem, while Ctrl+F5 does. So the question is not the difference between both (other questions have already addressed that), but rather: how can attaching a debugger to a C# process affect its behavior?!
The code creates a connection over the network.
In all kinds of ways. It affects JIT optimizations, garbage collection, timing (think race conditions), anything which explicitly tries to detect whether it’s running in the debugger, and potentially the order and timing of type initialization.
If you can now reproduce it, I would start adding logging and see where that leads you – once you’ve worked out what the problem actually is, you may well find it’s obvious why the debugger changes things.