1

We have a .NET Core 3.1 solution with 50 projects, only a few of which are executables.

The default behavior PackageReference seems to be to copy the assets to the project's OutputPath, and the default behavior of ProjectReference seems to be to copy the contents of the referenced project's OutputPath into the referencing project's OutputPath (or close enough). So in the end it all ends up into the exe-project's OutputPath, and running locally (with F5) works.

The problem is that all of those 50 OutputPath directories are hundreds of megabytes, and running a build will generate many gigabytes.

I'm aware that many would recommend we have fewer projects, but that's not an option right now. The solution of compiling everything to the same OutputPath will not work for us, because of reasons we can't change right now.

Turning off "Copy local" does avoid all the unnecessary duplication in those 50 library projects, but it also causes the exe-projects to not get the assemblies and assets that they need to run. Now I can turn it on just for the references in the exe-projects, but that will not copy the transitive dependencies.

I thought about adding post-build a target that will copy a project's output to the executable projects, but there is no way to know if that executable will actually need this project's output, so there will be some unneeded artifacts in the end.

I also tried turning off "Copy local" for everything and hoping that the "Publish" target would gather all into its output directory, but even that does not seem to gather the transitive dependencies. But this would not be ideal either, even if it did work, because I want F5 debugging to work, and that does not use "Publish".

So I'm wondering if there is a sane way to achieve the following: Every non-exe project compiles to their own directories, and do not get copies of their dependencies. The exe-projects get copies of the assets of all their transitive dependencies (both projects and packages).

I will just comment that I think MSBuild seems very archaic, with no real tracking and management of the dependency graph, the assets referenced, and their locations.

NotNull
  • 307
  • 2
  • 9
  • [1](https://stackoverflow.com/questions/280751/what-is-the-best-practice-for-copy-local-and-with-project-references?rq=1)and[2](https://stackoverflow.com/questions/26163368/is-copy-local-transitive-for-project-references?rq=1) Do these links help you? – Jiale Xue - MSFT Dec 10 '21 at 05:50

0 Answers0