I'm thinking of this: If projects share the same output folder, I guess there would be situations when some file could be get replaced by the build process by other version of the same file, causing issues. Am I right?

I'd say that it's not a good idea, but I would like to ask you for an authoritive answer.

CodePudding user response：

In my opinion, it is always better to have a separate output build folder for each project. Firstly, to avoid things like overwriting as you said and secondly, just from the context alone, projects should be treated separately, be it config files or builds. If you later also have CI/CD pipelines in combination with builds, these are also provided separately and via scripts you can then gather the necessary configurations accordingly or also copy e.g. static files (such as Javascript frontend builds) into the respective project folder, which is responsible e.g. for providing a UI (e.g. via .NET ASP and static files).

What you can also do if you can't avoid it for some reason, is to create at least a "subfolder" for the respective projects in relation to the builds, e.g. /bin/build/myProjectOneBuild and /bin/build/myProjectTwoBuild.

CodePudding user response：

Depends on what you want to do. Unrelated projects generally shouldn't output to the same directory because, as you say, it could lead to e.g. dependencies of different versions overwriting each other. However if you have a bunch of projects which logically belong together, like multiple executables which are to be distributed together or just form a set of tools together, or a program which uses a plugin architecture and each plugin is its own project, then it does make sense and is even convenient to have one directory. In such case there should also not be a risk with overwriting since e.g. plugin dependencies should then all have the same version anyway.