There are two types of reference in C # solutions, project references, and DLL physical file references.
I. Project References strictly referenced, the project file needs to be included in the solution, the benefits are easy to debug, direct access to the code. The disadvantage is that the coupling is too high (must all be compiled through to run), the project is too large to compile trouble, not conducive to deployment upgrades and testing. Because it is a strict reference, replacing the DLL alone is not working. And every time the upgrade program to recompile, package, uninstall, install, it is quite troublesome.
Second, DLL physical file reference loosely referenced, DLL physical files are referenced, DLL project packages are not included in the solution does not matter (generally included), the advantage is not to all recompile, where to modify the compilation where, but only if the DLL file must be placed in the path of the referrer, otherwise it will cause the compilation does not update the problem. Disadvantage is not conducive to debugging, because for inexperienced people, or just take over the new person, do not know the program architecture, and this method of debugging will not automatically enter the code snippet, you must attach process debugging, advance to the DLL code break point will be entered. This method is suitable for large programs, local compilation, easy to upgrade, test, deployment is simple (do not have to package, or you can make your own packager, because only need to copy physical files only). regardless of the reference, the referenced DLL is generated under the referrer's path, but the project reference is kept in sync, and the DLL physical reference does not update the DLL under the referrer path. Unless your own build path is the path of the referrer (or if you clean up or regenerate the referrer, this is not recommended, you typically specify the build path to the referrer path).
C # Development Pattern--dll Multi-level reference issues