Visual Studio Solution Project Reference or Dll Reference

Question

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:

• can end up with too many projects in the solution
• introduces fail fast updates since dll's can't be versioned anymore
• forces everyone to have a similar folder structure for their code

The downsides to lib folder reference:

• delayed bug finding since the dll could be updated much later in the project using it
• debugging isn't possible without up to date pdb files

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.

Answer 1

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.

Answer 2

We set up an internal Nuget server to handle this. This is has been an easy way to handle distribution and version management.

Answer 3

The approach I use is upload compiled dll into a server in post-build event of dll project and download them in pre-build event of the project I use dlls in. This is the best approach from my experience. When I used project references there were some errors ocasionally (as far as I can remember sth with dll code not updated correctly).

In this approach dll project coder decides when he wants to 'publish' the code.