In a Visual Studio C# solution, are there any disadvantages for all projects to share the same output path? I'd like to do this because we use dependency injection and the files don't get copied automatically (since they are not referenced). Will this cause me any problems?
(This is related to: C# - Copy dlls to the exe output directory when using dependency injection with no references?)
We are doing this on our current project. We have about 30 projects output to the same bin folder and we have not had any problems.
There's a potential problem if you have two different projects depending on different versions of the same assembly. If I have project A depending on X.dll version 1, and project B depending on X.dll version 2, you're not going to be able to place both versions of X.dll into the same output folder (without a rename). Admittedly, the chances of these aren't high, but they're not zero.
The point of having multiple projects is to produce multiple assemblies. Assemblies are a deployment mechanism in .Net. If you always plan to bundle all the output dlls into one package, then I do not see disadvantages in this approach.
However, if you are planning to deploy Assemblies A,B,C separately from Assemblies D,E,F for one reason or another, keeping the output directories separate will ensure that the correct assemnbly and only its dependencies are in the output folder. It will be easier to then just write a script that correctly bundles those Assemblies into the correct packaging that you want.
Generally not a disadvantage, I find it quite beneficial to have a single output location for my target assemblies. When VS sorts the projects for compilation by determining dependencies, it will overwrite an existing instances of compiled assemblies that have been built earlier in the build order.
Saves me having to hunt round for the compiled assemblies when everything is built.
Some instances where you may have issues is if you have two projects with references to external assemblies that are of different versions, you may end up with an assembly bundled without the incorrect version of a dependency...
You may run into issues w/TeamBuild or whatever automated build process that you are using if you are planning on deploying your assemblies in different ways (core package vs. add ons, etc.)
How you customize your build scripts will be different (not necessarily disadvantageous) depending on how much customization you've done to your csproj files.
One big disadvantage with this approach is often you will run into access violation issues if your startup project holds references to any dlls that other projects reference during the build, even if copy local = false. I run into this issues everyday now. I would suggest having a project with all the needed references and copy local = true for those references. This will also help with making an installer.
