Separate or identical folders for debug / release output when using .NET (C #)?

Question

What is the best practice for determining the target output folder for Debug / Release : is it better to have separate folders for debugging / release, or to use the <strong> same folder for both (when using .NET / C #)?

I have two separate solutions, therefore the projects of one solution cannot have a project link to the project of another solution. Thus, you are forced to directly reference the assembly file. This leads to another problem: if you add a link to another assembly via a file, you can add only one instead of one for debugging and one release of fore (for example, you can do with C ++ libraries). Another problem is that I have to add the link, for example, to bin / Release /MyOtherProject/MyAssembly.dll. I think this is confusing, especially when creating Debug and links to Release. => Build and version errors are possible.

Does anyone have a lot of experience in creating the same target folder in large projects and environments?

This is a more accurate question related to the issue of stack overflow. Should we still make a difference between release and output folders? .

Answer 1

We used the same directory for debugging and release in .NET applications for 10 years and never experienced any problems.

This approach greatly simplifies numerous tasks, such as building, copying custom DLL files to directories after assembly, and version files in output directories, such as license files, which developers need to run the application correctly.

Answer 2

If these are two different solutions, I see no good reason why you would like to reference Debug output. Actually, I don’t think you should reference the output in another project directory. Your links may be damaged if the code is transferred to another computer, and you cannot accurately reproduce the structure of the project.

I think the best practice will be to

1) You have a Lib directory in Project / Solution A, which you manually copy the output of Project / Solution B. Do this if you do not make changes to Project B. very often.

2) Put both projects in the same solution, then add a link to the project. Remember that you can have one project in several solutions. Do this if you are developing both projects at the same time.

Answer 3

If you have two related projects that care enough for you that they are in the same type and configuration (which means that you are not using any third-party package that you are using), you should put them in one and the same solution.

If for some reason you cannot , there is another (slightly ugly) solution.

You can edit your .csproj and "dynamically" target-based link assemblies. In the .csproj file, the links are inside an XML element called "ItemGroup". In each element group, you have many Link elements, and the assembly path is in the Tip element. You can put the $ (Configuration) variable in the tooltip. For instance:

<ItemGroup> <Reference Include="your assembly"> <HintPath>..\..\$(Configuration)\blabla.dll</HintPath> </Reference> </ItemGroup> 

Thus, the directory name will contain your configuration name (they must match - this means that if you change the names that you violate).

Another option is to define three groups that are completely different and use the Condition attribute:

• A group of unconditional elements that will be used to refer to System, System.xml, etc.
• A group of elements with the attribute Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' " , which will contain links that will be used in the debug configuration.
• A group of elements with the attribute " '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " for the Release configuration.

In each group of elements you will have a link to the assembly in the correct configuration.

This is a little ugly because .csproj is sometimes automatically modified, and you can easily forget and make a mess out of it. But in any case, it will work.