I'm looking for guidance on a project reference/dll reference practice.
The situation is that we have utility dll's that are used in a bunch of projects and some team members reference by project and some by reference in a dll.
The downsides to project reference are:
The downsides to lib folder reference:
Also, what would be a good strategy in making sure all projects still work with the dll updates? Would it need to be a build server firing dependency build checks whenever the utility is updated?
We're using SVN as our source control.
We do something similar to Peuczyński. We have a folder under the root of our source tree where all the dll, pdb, and xml doc files from our library assemblies go (so it's version controlled along like everything else). Other projects reference those (not directly to the lib projects or their bin dlls). That allows work on lib code without disrupting the development of regular solutions. Only when the lib code is solid is it 'published' to the official lib folder (where all the dlls, pdbs, and xmls go).
One little hack that allowed us to have both debug and release versions, and have Visual Studio pick up the proper one in the projects using the library code without funky pre build stuff was to have three subfolders under the Libs folder, with those folders named as follows: $(Configuration)
, Debug
, and Release
. When adding a reference to a library dll, you always pick the file from the $(Configuration) folder. That folder name tricks VS to actually use the dll from the Debug or Release folder, depending on which type of build you're doing.
We set up an internal Nuget server to handle this. This is has been an easy way to handle distribution and version management.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With