Lets say I have two projects A and B. A depends on B. I can specify this in two ways:
- Include A and B in the same solution and specify B as a project dependency for A. This shows up in A’s msbuild project as a “ProjectReference” node.
- Include a reference to the B’s compiled dll as dependency for A. This shows up in A’s msbuild project as a “Reference” node
My question is, once I’ve build the assembly for A, is there a difference in the final output between these two methods.
I tried creating a couple of simple projects which model this relation and tried a comparison – but different comparison tools are telling me different things. Pending writing something which compares these files byte-by-byte, I was wondering if you folks knew anything about this. Specifically, will there be any difference in the behaviour of the built assembly if I use dll reference instead of a project reference.
If the project B sources have not changed in between two builds of project A, there will be no difference in the behavior of the project A output. However, if project B sources have changed, referencing it as a project from project A will cause project B to be rebuilt as well. This difference is what determines your choice of how to reference project B from project A:
if you own the source of both project B and project A, and they are tightly coupled, or if they both are under active development and project B undergoes often breaking changes of its public interface, you want to reference project B as project. This would ensure that project A always uses in its build the most up-to-date output of project B.
if project B is external dependency you don’t develop yourself, or you don’t have the sources to, or if it has been shipped already and you can’t ship modified version with project A, you want to reference the pre-built project B output, to ensure you are developing and testing with the same version of project B, that is most likely to be on your users’ computers.