Why have separate Debug and Release folders in Visual Studio?

Question

By default, of course, Visual Studio creates separate bin folders for Debug and Release builds. We are having some minor issues dealing with those from the perspective of external dependencies, where sometimes we want release binaries and sometimes debug. It would make life slightly easier to just have a single bin folder on all projects and make that the target for both Debug and Release. We could then point our external scripts, etc. at a single location.

A co-worker questioned why we couldn't just do that--change the VS project settings to go to the same bin folder? I confess I couldn't really think of a good reason to keep them, other than easily being able to see on my local filesystem which are Debug and which are Release. But so what; what does that gain?

My question(s):

• How do you leverage having distinct Debug and Release folders? What processes does this enable in your development?
• What bad thing could happen if you fail to retain this distinction?
• Inversely, if you have gone the "single folder" route, how has this helped you?

I am NOT asking why have separate Debug and Release builds. I understand the difference, and the place of each. My question concerns placing them in separate folders.

Solution 1

The way I see it, this is simply a convenience on the developer's machine allowing them to compile and run both Debug and Release builds simultaneously.

If you have scripts or tools running inside Visual Studio, the IDE allows you to use the ConfigurationName and other macros to obtain paths which are configuration-independent.

If you are running scripts and tools externally from the command-line (i.e. you are structuring some kind of release or deployment process around it), it is better to do this on a build server, where the distinction between Debug and Release goes away.

For example, when you invoke msbuild from the command-line (on the build server) you can specify the Configuration property for Debug or Release, and the OutputPath property to build to one location only (regardless of the Configuration).

Solution 2

Dave, if you will compile Debug and Release to single folder, you may encounter the situation where some dll-s will not be recompiled after switching from Release to Debug and vice versa because dll files will be newer than source files. Yes, the "Rebuild" should help you, but if you forget this - you can have a few extra hours of debugging.

Solution 3

One reason I use separate folders is that it guarantees that I only generate installers that use Release-build code. I use WiX, which allows me to specify the exact path to the files I want to include in the installer, so I end up specifying the path in the Release folder. (Of course, you can do the same using normal VS installers, so that isn't really the point.) If you forget to switch your project to Release before building, the installer doesn't build unless you have old code in the Release folder, in which case you end up with an old installer, so that's a bit of a pitfall. The way I get around that is to use post-build event on the WiX installer project that clears out the release folder after the WiX installer builds.

Solution 4

In a previous company we got round this problem by changing the names of the debug executable and dlls by appending a "D". So

MainProgram.exe & library.dll

become

MainProgramD.exe & libraryD.dll

This meant that they could co-exist in the same output folder and all scripts, paths etc. could just reference that. The intermediate files still need to go to separate folders as the names of these can't be changed.

Obviously you need to change all your references to point to the modified name for debug - which you will forget to do at some point.

Solution 5

I usually compile in Debug mode, but sometimes need to compile in Release mode. Unfortunately, they don't behave exactly the same in certain error situations. By having separate folders, I don't need to recompile everything just to change modes (and a full recompile of our stuff in Release mode will take a while).

View more solutions

Comments

[Michael S. Scherotter]

You should have a post-build step setup in the project to copy files to th ebinaries directory.

[stijn]

I use this for dlls as well, and all my dlls go into one directory that is in the system path.

[bta]

Exactly. Using the same folder can lead to the situation where you build a binary where half of your source was from a Debug build and half from a Release build. Definitely not a fun situation to debug.

[Seth Petry-Johnson]

I prefer using a build script with a "release" target that does the release build for me. That way I don't even have to think about what build configuration VS in in, I just run the release command and then sit back and sip my coffee :)

[Russell]

Totally agree, WiX+msbuild+CI tool makes for smooth building and smooth coffee!