Project reference vs. dll reference

First of all, I want to say that this is an engineering decision rather than an architectural decision.

If you look at the package diagram, component diagram, and the responsibilities of these components, whether we are doing dll reference or project reference there is no difference in these architectural elements. When the system is built into  MSI package or deployed to computers, there is no difference whether we are doing Dll reference or project reference. It is the decision on how we build these components in the system rather thanen how these components related to each other.

let’s take a closer look at this issue. If you Google “project reference vs. dll reference” you will get a long list of links, I randomly picked up a few and copied here:

  

It's not much of a choice. If you have a solution with both projects then there's no point in not using 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

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.

Q:I was just wondering if you can share your experience in better development practice. Let’s say you application consist of several projects which produce several dlls. Some projects reference several of other and so on. When I want to make any changes to one of the project or create a new project that uses one of the existing ones. What would be better is to include reference to but dll of existing project or include project into the solution and add reference to the project. I am just a little confused in difference of building process. As far as I understand in case of adding reference to the project as oppose to DLL the project that is referenced will be built as well and assembly version will be incremented

A: Always i.e. ALWAYS add the project of the assembly (i.e. dll) to the project which is going to produce an executable. This really, and I mean REALLY simplifies development. I don't know what more I can say...

If you add an assembly as a reference, the IDE will keep the dll open, which means if you've got 2 versions of DevStudio - one for the exe, one for the dll then it won't work. If you add the assembly as a project reference everything works fine.
And of course source safe integration ensures that you always have latest version of the dll code if you have everything in one solution: rather than you having to go off and do it manually.

IMHO, it is determined by development team structure. If the development team is structured in such a way, all members are responsible for both referred component and referring component. You will want use project reference. There are 4 major advantages in doing so:

1. There will be no build dependency among different solutions
2. The build process will be as simple as “get latest and build” for all solutions
3. Each solution always get the right edition/ version of the dll (release /debug), all that need to do is get latest and build
4. Easy debugging in stepping through between referred component and referring component.

On the other hand, if the development team structured in such a way,

1. One team is responsible for referred component and another team is responsible for referring component. 
2. The source code of respective component is only made available for respective team.  
3. There are formalized release schedule for one team to release referred component to another team.

In this case, DLL reference is the only way to go. After all, project reference is not possible as the source code of both components are not available to either team at the same time.

  

However, as it is an engineering decision rather than architectural decision, we can change it as the development team structure changes.  When we have two teams for two different part of the system, we do dll reference; when we have one team for both referenced component and referring component, we do project reference.

Conclusion : it is correct to have them as dll reference when we have multiple teams responsible for various components; it is also correct to change them to project reference when we only have one team for both referenced component and referring component.  When we make it project reference, we are making the referred component a shared project in multiple solutions.   We will enjoy the following benefits if we do project reference:

1)    There will be no build dependency among solutions. This is true for both developers and build team.

2)    For any solution, all we need to do is get latest source code and build, we will get the correct edition (release / Debug) and correct version (latest version), This is true for developers, it is also true for build team.

3)    when we debug, we can step into all components for debugging process

4)    We no longer need treat dlls as source code and check them into version control (e.g. TFS) even they are not source code.  

When we do project reference, we basically let the component participate in multiple solutions. In another words, we are treating the component as shared component among multiple solutions. When we are doing dll reference, we treat the dll as deliverable product from provider point of view and treat the component as third party component from consumer point of view.

In the case of shared component, it is import to ensure the code change of the component works as expected in all solutions it participates in before we check in any code change. Failed in doing so would break the build or break the functionality of the system.  It is also important to note that the refactoring functionality provide by IDE only works within the solution where the code change occurs.  

In the case of third party component development, the provider team needs to follow certain SDLC process before releasing the component to its consumers to ensure the quality of the product. Artfacts like API documentation, release notes should be provided when a new version of the component is released.  It is also a reasonable expectation from the consumers that this component is backwards compactable at least to its immediate previous version. From consumer point of view, to protect the integrity of their work within its scope of work, it is highly recommended to put in place some assert unit tests to safe guard the behavior of the component. This is so that when the behavior of the said component changed cause the system misbehaving , the consumers are notified, they will communicate the issue to the provider without trying very hard to find where it went wrong in its own scope of work.