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?
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.