6

What is the best practice for defining the target output folder for Debug/Release: Is it better to have separate folders for Debug/Release or should I use the same folder for both (when using .NET/C#)?

I have two separate solutions, so the projects of one solution can't have a reference by project to a project of the other solution. So you are forced to add a reference to the assembly file directly. This results in another problem: If you add a reference to another assembly via a file you can add only one instead of one for debug and one fore release (like you can do with libraries in C++). Another problem is that I have to add a reference, for example, to bin/Release/MyOtherProject/MyAssembly.dll. I think this is confusing, especially when building Debug and having referenced Release. => Build errors and version conflicts may occur.

Has anyone long experience in building into the same target folder in large projects and environments?

It is a more precise question related to Stack Overflow question Should we still make a difference between the release and debug output folders?.

Community
  • 1
  • 1
Beachwalker
  • 7,685
  • 6
  • 52
  • 94
  • 5
    VS automatically creates separate directories. – Sam Axe Jan 24 '12 at 19:59
  • ... but if you add a reference to another assembly you can add only one instead of one for debug and one fore release. If I have several solutions (currently platform dependent) I have to add a reference e.g. to bin/Release/MyOtherProject/MyAssembly.dll. I think this is confusing, especially when building Debug and having referenced Release. => Build errors and version conflicts may occur – Beachwalker Jan 24 '12 at 20:13
  • 2
    If you are concurrently developing the other assembly, the project for that should be part of one solution. That way both are compiled in the same configuration (Debug or Release) together. If the other assembly is a separate endeavor, then I would use the Release version so that the Debug version does not slip into your Release project files for the other project. – Kevin P. Rice Jan 24 '12 at 20:21
  • 2
    We currently have too much project files (assemblies, dynamically loaded and exchangeable via spring) to build them in a single solution. VS + Resharper becomes very slow when the solution is that big. So having one solution is not an option. – Beachwalker Jan 24 '12 at 20:25
  • Possible related question: http://stackoverflow.com/questions/4956005/ – Kevin P. Rice Jan 24 '12 at 20:29

3 Answers3

5

We have been using the same directory for debug and release in .NET applications for 10 years and have never had a problem.

This approach makes numerous tasks substantially easier, such as building installs, copying custom DLL files to directories post-build, and versioning files in the output directories such as license files that are necessary for developers to run the application correctly.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
competent_tech
  • 44,465
  • 11
  • 90
  • 113
4

If they are two different solutions, I don't see a good reason why you would want to reference the Debug output. In fact, I don't think you should be referencing the output in the other projects directory at all. Your references could be broken if the code is moved to another machine and you don't perfectly replicate your project structure.

I think best practice would be to either

1) Have a Lib directory in Project / Solution A that 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 reference to the project. Remember, you can have one project in multiple solutions. Do this if you are developing both projects at the same time.

cadrell0
  • 17,109
  • 5
  • 51
  • 69
  • 2
    Correct, also if Project A is under Source Control (TFS) Project A and Project B is under Source Control Project B, you can check in both A and B from one solution, which is quite nice. – John Jan 24 '12 at 20:49
  • The release output should not have the debug symbols (neither inside or as pdb-file) from my point of view. An option would be the removal of pdb-files as post build step during the setup build. – Beachwalker Jan 25 '12 at 10:09
  • We currently have too much project files (assemblies, dynamically loaded and exchangeable via spring) to build them in a single solution. VS + Resharper becomes very slow when the solution is that big. So having one solution is not an option (see comments at the the top). Another reason is the delivery by external components right into the repository and CI which should coop with the current/latest development (an option to solve that would be to decouple unittests from the delivery but this would cost affords for changing unittests during api changes). – Beachwalker Jan 25 '12 at 10:12
  • Your suggestion no. 1 is in use for an internal delivery or external dependcies. But the two solutions A and B from my example (in fact more than two... 40 solutions to be precise) can not use this aproach, I think. – Beachwalker Jan 25 '12 at 10:20
  • 1
    "The release output should not have the debug symbols (neither inside or as pdb-file) from my point of view." also assemblies built in debug mode are not optimized. The difference between Debug and Release is not only the pdb and xml files but also instruction optimization in the IL. – tobsen Jan 25 '12 at 22:35
  • Correct. There are some more options you can set differently for debug/release/... configs via vs ui (especially the IL optimization you already mentioned or think about conditional compilation symbols)... Still the question is: Do we really should differenciate the *output folders*? Don't you think two target folders increases the complexity of scripts and references, too (nant, FxCop etc.)? I think, the differenciation of the output folder is nothing more than a "we-allways-did-it-this-way-in-the-past" convention and is not really a benefit those days in the .Net-world. – Beachwalker Jan 26 '12 at 10:44
4

If you have two related projects that you care enough about them being in the same target type and configuration (which means it's not some third-party package you just use) - you better put them in the same solution.

If you can't for some reason, there is another (A bit ugly) solution.

You can edit your .csproj and "dynamically" reference assemblies based on the target. In the .csproj file the references are inside an XML element called "ItemGroup". In each itemgroup you have many "Reference" elements, and the path to the assembly is in "Hint" element. You can put $(Configuration) variable in the hint. For example:

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

This way, the directory name will include your configuration name (they should be match - which means that if you change the names you break things).

Another option is to define three completely different item groups and use the "Condition" attribute:

  1. Item group with no condition that will use to reference System, System.xml, etc.
  2. Item group with attribute Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' " that will include the references that will be used in Debug configuration.
  3. Item group with attribute " '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " for Release configuration.

In each item group you'll have reference to the assemblies in the correct configuration.

It's a bit ugly, because the .csproj sometimes modified automatically plus you can easily forget and make a mess out of it. But anyway, it'll work.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Shahar Gvirtz
  • 2,418
  • 1
  • 14
  • 17
  • The usage of $variable expressions worked (or say works) well in Visual C++ projects, I have used them myself. But in C# projects with VS is there a problem that you can't enter those variables using the ui (as you can do in C++ projects). Personally, I don't like things you can not express using the IDE and need to edit a file by hand after a change. Nevertheless, your suggestion is working and a way to solve the problem. Thx. – Beachwalker Jan 26 '12 at 12:06