What is the purpose of debug/release configurations in Visual Studio 2008/2010 compiling to different folders?

Question

What is the point of compiling assemblies to separate folders? At my work we have 50+ projects which live across a few different solutions. When projects are in the same solution you can set a Project Reference and it picks up the assembly in the \debug or \release folder accordingly. But when setting an external reference (via Browse) and you point explicitly to \debug\assebmly.dll or \release\assembly.dll the referencing project will not pick up a "release" assembly if the referenced project is compiled in release mode.

I understand that normally a build process can handle this, but in the case where I need to compile a project in release mode outside of a build process this means I have to check all external references to make sure they are pointing to the \release folders. This is something easy to miss - and I do not want to have to think about everytime. So my thoughts are to always compile the assembly for a project to the \bin folder whether debug or release configuration is selected. Any cons to this approach?

I also have a blog post on this topic here.

Answer 1

You can't tell at a glance which version (debug|release) you're looking at? And in fact it makes it harder after the fact to tell which one you've referenced - since the one referenced could be either debug or release.

Answer 2

It's not only the binaries, it's the intermediate files as well. That's why it's necessary to compile to different directories.

If you want to have your binaries in a bin folder, then change the output file or add a copy as a custom build step. I understand that this adds some inconvenience to your workflow, but you have to realize that building to the same folders by default would be a huge PITA for a lot of people.

Also, when adding references to projects outside of your solution, try to use macros like $(ConfigurationName) in your reference to automagicaly insert "Release" or "Debug" in your path as necessary. (I envy you for only having to deal with the two default configurations...)

And then, here is another idea: Projects can live in more then one solution. Have a solution for each valid combination of projects that you have to build. This way you will allays use the Project Dependency feature and will always build up-to-date builds of your solution with one click.

HTH

Answer 3

Well, it is simple, because not using separate folders is so much worse. You'll build Release, find out something is amiss, switch back to Debug and not get the actual Debug versions of the assemblies. Unless you explicitly use Build + Clean first. Now you'll go sword-fighting or visiting SO, forgetting why you switched back.

Dealing with project output from another solution is straight forward too: always add a reference to the Release version. Because if you needed to debug and alter that assembly then you would have added the project to your current solution.

Answer 4

If you build everything in to a single folder, switch configurations, and then do a partial solution build (say, just of your data component), you can easily end up with a mixture of debug and release assemblies being used. That's a Bad Thing.

By keeping the builds in separate folders, you can ensure that all assemblies are built from the same configuration.