(This articles has already been posted in www.msd2d.com. Now I post it again in my own blog.)
Ever reference to strong named assembly? Referencing to an assembly or other project within solution is common task in object oriented programming environment. For example, when you have made a generic library that hold base class for the next projects, you will need to create a reference to that library so you can derive from the base class. Basically you can create reference to any library – however in strong named environment there is an additional requirement; that is you can only create reference to strong named library. Likewise the ordinary solution, you can also create reference to strong named projects. But do you realize what differences between those types of referencing are? This article will discuss the differences within strong named solution.
Usually when you want to make project reference, your projects must be in the same solution. Referencing to other project will add new dependency to current project, which in turn control build order of your project. So in this cases the builds always done in order, guarantees that you will have the latest build of assemblies. Even when you only change small part in derived assembly, the compiler will automatically rebuild all dependencies.
In non strong named assembly, the derived part will only create reference to assembly name – consequently rebuilding all dependencies won’t create a problem. However when referencing in strong named assembly, not only assembly name is referenced but also other build information (such as build time) – i.e. hashed reference. Hence, redeploying this kind of solution requires replacing all installed assembly from your solution. Problem arises when the base assembly is referencing by many projects and placed in global location. Replacing the base assembly distort hashed reference in other projects (which is not within same solution).
Contrast with project reference, referencing to assembly will not change the build order of project. Recompiling your project will only modify the derived assembly – therefore the hashed reference will be the same. As a result, redeploying this kind of solution only requires redeploying the derived assembly.
For better independency, better to choose assembly reference as it won’t impact to other assemblies referencing to the same base assembly.