48

I know there are other questions regarding this subject, and I've looked at this question, but I'd like to see a little bit more discussion and information on both sides of this - is it a better practice to add a project to a solution and reference the project, or to add a reference to the .dll?

Improve this question

5 Answers 5

Reset to default
38

It's not much of a choice. If you have a solution with both projects then use a project reference. If your solution doesn't have the project then you have to use an assembly reference.

So the real question should probably be: do I create a solution with both projects? Yes, as long as the project is still in the debug stage and liable to require bug fixes.

Improve this answer
4
  • 21
    It's more complex when you have several solutions. Using a project reference can break the build of other solutions that include the referencing project and not the referenced project. Visual Studio then resolves silently(!) the project reference into a file reference to the dll in bin/Debug, which is unexpected and breaks if the solution compiles in Release.
    – Eldritch Conundrum
    Commented Jun 6, 2012 at 12:40
  • You can solve this by adding the parent projects first to your solution always, and don't add any project without it's parent (referenced) projects
    – Saw
    Commented Mar 1, 2013 at 18:10
  • 1
    Just to add - if you use dll reference on project A when you click "Find all references" on a method from project B, the method reference from project A won't appear at all = recipe for mistakes
    – BornToCode
    Commented Aug 21, 2014 at 12:47
  • @EldritchConundrum, I think I'm having that problem, but for some reason the Release build works out ok, it just causes the Debug build to fail, but only on the proper Azure Devops build, it always works fine locally
    – Peter Nimmo
    Commented Aug 21, 2023 at 9:23
24

If you only have the dll then you're stuck with a dll reference (obviously).

If you have the source then it's usually better to use a project reference. There might be cases where you have a utility library that's never going to change, but if there's the slightest chance of you needing a bug fix then having a project reference is going to make debugging a lot easier.

Improve this answer
6

Summary - Project Reference by Project vs by DLL

Reference by project

  • code is visible
  • finds all references e.g. on a class (because code is visible)
  • better for testing (over all)
  • better for code redesign (impact)

Reference by DLL

  • code is hidden
  • separation between e.g. framework and project (for deliver of framework)
  • quicker compilation (because DLL is already compiled)
Improve this answer
3

Well, project references are helpful when you are building and testing in both debug and release mode. If you directly add a DLL then you are locked into whatever that particular DLL was built as. The project reference allows this to be a build time decision.

Improve this answer
1
  • This is correct what you are saying. At the same time it is not causing issues when working with .NET assemblies. They contain IL code which is compiled later on a destination machine at first run. A very nice time for decisions.
    – Mikhail G
    Commented Jul 22, 2013 at 7:46
-3

Relative to your project architecture, you should always stick to projects within your problem domain. You should be using the GAC, if that is applicable to your environment.

Improve this answer
1
  • 5
    How has the GAC anything to do with project references vs dll references in a Visual Studio project file?
    – Abel
    Commented Sep 16, 2014 at 18:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.