I was curious what the differences are between the debug and release modes of the .NET compiler and came across these questions about debug vs release in .NET and reasons that release will behave differently than debug. Up to this point I really haven't paid much attention to these compiler modes. Now I will.
My question is, assuming that I am using a testing framework (NUnit) and TDD, would I run into any issues if I simply always compiled in release mode?
You're using TDD. You write your test. The test fails. You write the code to pass the test. The code fails. You look at the code you wrote and can't see any obvious reason why it fails. Do you reason some more or start up the test in the debugger (using TestDriven.Net) and step through the test? Maybe I'm just not smart enough to always figure out why my code doesn't work, but I usually do the latter when I'm stumped.
For debugging.
Like tvanfosson said, even if you usually don't use the debugger (I know I don't), sometimes you need to.
Debug mode turns off a lot of the optimizations. This means when you get a stack trace it will look more like the original code.
A pretty significant difference between the debug and release configurations is that calls to methods marked with ConditionalAttribute are only compiled if the associated symbol is defined. So your calls to methods of the Debug class don't get included if you compile using the release configuration.
This lets you festoon your code with assertions and code that dumps information to the console, and yet be confident that none of that overhead's going to appear in your shipping code.
Also, edit-and-continue is an extremely useful tool, and it relies on metainformation that's omitted from release builds.