VS.NET: Project Refs vs. Assembly Refs

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 wa开发者_如何学Goit 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.

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.

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.

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.