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, especially since we have automated unit tests that prove that the common code does what it needs to.

The thought from the other camp is to lock down those projects and only release assemblies once a month or something. Then force all projects to reference the assemblies. They think this will protect them from deploying untested code. They are "too busy" to write automated unit tests and configure their projects for continuous integration and I have no influence on that, so please do not focus on this aspect.

Here's the reasons I can think of why project references are the better solution. I'm looking for other opinions as well.

PROS:

• Referencing projects ensures you are working with the latest code. You don't have to wait on anything.
• Reducing duplication. Without having the latest code, there is a greater chance of reinventing the wheel.
• If a developer needs something and can't add it to the assembly where it belongs, it will be created in any location that will work, creating many inconsistencies and code duplication.
• Development is easier because you can easily see/debug what is happening in the referenced code.
• Our common stuff doesn't change that often, but when it does, it's usually something useful. Why add the extra burden of maintenance and assembly release management.

CONS:

• Could possibly take longer to load.
• Can take slightly longer to add projects to a new solution then adding assembly references.

Answer 1

Here are a couple of pros you missed

• Live Updating: Features like intellisense will update automatically between project to project references as you are changing the APIs
• GoTo Definition: If you have an assembly reference, GoTo Definition will take you to the actual code definition. With an assembly reference it will take you to the generated metadata signature.
• Find All References: Will process all code in project references for use of a reference. For an assembly reference you will only see uses within the metadata
• Quick Search (2010 only): Similar to find all references, just works better in a P2P reference

In response to your cons

• Yes: Loading a project is typically slower than loading a reference. With a reasonable amount of projects though this time difference is not significant and should not impact your daily development routine
• Yes: Adding adding a project to the solution is generally slower than adding a reference. The difference though is in seconds and is a one time cost. I think it's a mistake to consider this as part of the criteria.

Answer 2

Well, if you are using any type of source control you could satisfy both camps. Using Branching or Labeling (depending on your source control).

Basically if you have a team that is in control of your common code they can branch / label a stable release. Then your projects would use the stable release. This protects you from deploying unstable code for your other projects while providing you the ability to test, debug, and view all the source.

Whenever your common controls team creates a new stable build you can update your source references to pull from the new branch.

The other up side to this scenario is you could have a patch on the common code so as not to mess with the current ongoing development efforts. Of course this does add an extra management burden of updating the common code in more than one place where necessary.