VS.NET: Project Refs vs. Assembly Refs

Question

There\'s some debate here over which is better for referencing our common code base from other projects: by project or by assembly. I\'m in favor of referencing the project

Answer 1

REFERENCING STRATEGY WILL ALWAYS BE A COMMON PROBLEM

I know this is a very old question but it will always be a relevant question with relative answers and I remember having this same question a few years ago and the impact of the two choices (project versus assembly references) only became apparent to me during the last two years while I was working full time on a builder for a system with 800+ projects in 300+ solutions for a single WPF app.

PROJECT REFERENCES ARE IDEAL FOR VISUAL STUDIO

Project references are ideal because you give the IDE much more insight into the details of your code because you are explicitly telling Visual Studio where the referenced project and all of its code is. If you are working on a system with less than 200 project modules and can afford to have only a few solutions (project groupings), go for project references because Visual Studio can do more for you with that extra information during design-time like showing you the code instead of reflecting referenced assemblies.

ASSEMBLY REFERENCES CAN SCALE BETTER

If your system is much larger than 200 projects, your builds may become very slow. I've seen 20 minutes per build and that really sucks. So if you can reference a DLL that doesn't change, you are telling Visual Studio "NOT" to build it, and that obviously has some impact on the time to build.

ASSEMBLY REFERENCES CREATE AN ILLUSION OF A DECOUPLED SYSTEM

Project references offer you a smarter IDE that always knows where and in how many places a type is used, where the code can be found, and some other useful statistics because all the projects are referenced directly. It can also warn you when you inadvertently tried to create a circular reference.

PROS of assembly references:

1. By treating some projects as external dependencies, you can create smaller solutions and smaller groupings of related projects, because unrelated projects are treated as external assemblies
2. Allows Visual Studio to handle very large modularized systems quite well.
3. Forces you to work out a dll/assembly staging strategy during the build process.

DISADVANTAGES of assembly references:

• Circular references become possible, and your less experienced developers won't notice those references initially.

  You can get around this challenge of circular references by treating one of your assemblies as a third-party assembly that its checked in, carrying it over to next version, and building it last. When a build fails on a project that uses this excluded assembly you can decide to rebuild that nominated project and often times massage out the circular dependency. (NOT RECOMMENDED, but it is possible)

• Upward framework references become possible as well because you add references to dlls that are compiled against a higher .net framework, and Visual Studio doesn't give you clear root cause messages when this happens so you will try many things to fix the problem and fail many times before figuring out to fix the framework versions.

  New projects default to the latest version of the .net framework not considering the fact that all projects in the current solution are still in an earlier version of .net, so when you add a reference to that project using an assembly reference, you will often times get a strange error that is not so easy to figure out.

• Cross-branch references also become possible because you are probably working in more than one branch at the same time, and sometimes get confused while adding a reference.

  You click "add reference", go a few directories up, go a few directories down, select the dll and click add without realising that the dll is actually too far up and down into another branch that you are also working on. This problem will only become apparent much later when the build server tries to resolve that assembly and fails. And the error "unknown namespace, are you missing an assembly reference?" will not help you at all wasting your whole team's time.