I'm working on a large enterprise .NET software. Currently the code is organized in 400 projects grouped in almost 50 solutions. The folder structure containing code and other artifacts is about 9GB, but after the product is built, it consumes about 70GB. This is becoming an issue for developers because they normally work on different versions of the product and each one is consuming the same amount of disk space.

The main reason for this waste of space is because the build process is producing a very large set of copies of the same assembly even where it is not strictly necessary. Basically every intermediate class library project contains all the dependencies assemblies in its bin folder, where they are not needed at runtime.

For dependencies:

• within the same solution we use project references
• across solutions we use assembly references
• for third parties components we use package references

I know that I could avoid copying dependencies in output bin folder (e.g. using CopyLocal=false or equivalent for project references and package references) but in this way, when a project is consuming an assembly in another solution, transitive dependencies are not copied even when they are really needed (for example when the project is an executable). This is causing issues at runtime or during unit test execution.

I tried to replace all assembly references with project references, even when the project is in another solution. In this way, I noticed that dependencies are correctly managed and transitive dependencies get copied properly. However, I'm a little bit scared of using this approach since it seems not natively supported by the IDE: in fact Visual Studio does not allow you to add a project reference to a project that is not in the current solution. My fear is that developer will have glitches in the IDE if I change dependencies in this way.

Do you have any suggestion or similar experience? The goal would be to minimize the number of copies of the same assembly across all projects and limit them to the minimum in order to reduce the disk space requirement.

CodePudding user response：

I tried to replace all assembly references with project references, even when the project is in another solution. In this way, I noticed that dependencies are correctly managed and transitive dependencies get copied properly.

This is the way I would tackle this, especially since it seems to be working for you. However, as you've discovered, this means everything will need to be in a single solution. Enter filtered solutions.

Take Microsoft's lead, for example. In the dotnet/aspnetcore repository, they have 562 csproj files. However, instead of breaking these projects apart into separate solutions, they have a single solution in the root that contains everything, AspNetCore.sln.

Obviously having a single solution that large isn't going to play very well with the IDE. To solve this problem, Microsoft introduced filtered solutions in Visual Studio 2019. This feature basically provides a way of specifying a subset of projects in the solution to load. This allows teams working on entirely separate aspects of the same solution to be able to load only the projects they need.