Reference all required assemblies for runtime or compile time?

Question

I thought this would have been a question already asked many times, but I can't find it.

We are developing applications and have multiple shared assemblies which are used by multiple targets. When I'm creating a new application I'll probably use such a assembly (eg Framework) and reference it in my project. All fine here. However, when this Framework assembly uses for example the Model assembly, I'm not forced by Visual Studio to reference it. As long as my code doesn't touch any Model types, it will compile fine without a reference.

At runtime, it does require the Model assembly. When releasing this application there is no problem, as I just include all the required references in my installer project.

The problem arrizes when I try to debug the application. The bin folder won't have the Model assembly as it's not referenced.

The question
Is there a best practice to solve this "reference of a reference" situation?

Solutions we've come up with

Add the Model as a reference
This feels wrong, we pollute the project

Include the Model project in the solution and add as project reference
This feels even worse (polluting the solution)

Add post-build step
Could be a solution, but doesn't feel that right either.

Answer 1

The best solution for this is to package your Framework or Library assemblies (or sets) with NuGet. You can then use NuGet in Visual Studio to take care of all these references. This works great, even when using nested dependencies.

NuGet is fully supported and integrated into Visual Studio. It is very easy to host your own package repository (that can be as simple as pointing to a file share with packages).

You can host a private on-site repository for your own (internal) pacakges. That's what most shops do. You can combine that with one or more public NuGet repositories for public things as Log4Net etc..

And while it may seem to take some time to get this up and running (which is relative, try to just use a public package first just to get the hang of using NuGet first), you get a whole lot of benefits as well. For example, you get support for versioning your libraries out of the box.

At my company we've had this problem for years, and we used to build and check-in library assemblies (50+) into source control, and dragging that around across branches. Since we've switched out approach to using NuGet, this problem just gone away for us. Never looking back to that anymore.