Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Difference between project and dll dependencies in .Net in the final compiled assembly

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.

like image 555
Rohith Avatar asked Sep 15 '10 04:09

Rohith


People also ask

How does .NET determine DLL dependencies?

Load your DLL into it, right click, and chose 'Analyze' - you'll then see a "Depends On" item which will show you all the other dll's (and methods inside those dll's) that it needs.

What is the difference between dependencies and references in Visual Studio?

They are basically no different, they are used to store and manage references. Just as Lex said, the Dependencies is a better way to represent different types of references, we can clearly know where the reference comes from, SDK, nuget, etc. so that we can manage our references more efficiently.

Is a DLL an assembly?

An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. Assemblies take the form of executable (.exe) or dynamic link library (. dll) files, and are the building blocks of . NET applications.


2 Answers

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.

like image 64
Franci Penov Avatar answered Oct 10 '22 10:10

Franci Penov


Adding as project reference just has the advantage that assembly "B" is automatically built if required.

Once assembly "A" is built, there is no difference.

like image 32
Hemant Avatar answered Oct 10 '22 10:10

Hemant