When should I use a project reference as opposed to a binary reference?
13:08 05 Sep 2008

My company has a common code library which consists of many class libary projects along with supporting test projects. Each class library project outputs a single binary (Company.Common.Serialization.dll). Since we own the compiled, tested binaries as well as the source code, there's debate as to whether our consuming applications should use binary or project references.

Arguments in favor of project references:

  • Project references allow users to debug and view all solution code without the overhead of loading additional projects/solutions.
  • Project references assist in keeping up with common component changes committed to the source control system as changes are easily identifiable without the active solution.

Arguments in favor of binary references:

  • Binary references simplify solutions and make for faster solution loading times.
  • Binary references allow developers to focus on new code rather than being distracted by code which is already baked and proven stable.
  • Binary references force us to appropriately dogfood our stuff as we would be using the common library just as those outside of our organization would be required to do.
  • Since a binary reference can't be debugged (stepped into), one is forced to replicate and fix issues by extending the existing test projects rather than testing and fixing within the context of the consuming application alone.
  • Binary references ensure that concurrent development on the class library project has no impact on the consuming application as a stable version of the binary will be referenced rather than an influx version. It would be the decision of the project lead whether to incorporate a newer release of the component.

What is your policy/preference when it comes to using project or binary references?

standards coding-style