Which method of setting references is considered more stable? Setting a
refference to a project or its dll.
Is it a best practice to always reference a project instead of a dll
when the actual project source code is available?
Currently various projects in my solution have a mix of project and dll
references. Of course 3rd party dlls are always referenced directly.
Can referencing dlls instead of the project cause odd errors?
The rule I use is that if the reference is to a project that is in the
current solution, it should be a project reference, so that the build
of the solution will automatically manage the binaries produced.
If the assembly reference is to the DLL, which is compiled from code
that I own (and is not in the current solution), then the DLL should be
in a folder that isn't automatically updated, such as the "owner"
projects \Bin\Debug folder.
Solution1
Project1a
Project1b
references Project1a
Project1c
references Project1a
references Solution2\_Assemblies\Project2b.DLL (copy local=true)
(will copy Project2a.DLL as well)
Solution2
Project2a
Project2b
references Project2a
_Assemblies\Project2a.DLL, Project2b.DLL
When I work on Solution2 and do a compile, the binaries get put in the
normal place (project\bin\debug) and then when I have completed my
work, I will manually copy the assemblies to the _Assemblies folder.
That way, Team A can work on Solution1, and Team B can work on
Solution2, and Team B can release in a controlled fashion their updates
that Team A depends on.
This works nicely in source control too - the _Assemblies folder is
part of the source code tree (but it is the binary assemblies which are
stored in source control).
Mike