C# – Advantages of using .dll files over linking .cs files to projects (for the own generic helper classes / extension methods)

cdll

I have a helper project which I use in all the applications that I create. It contains some extension methods and a bunch of generic helper classes, controls etc. I update/extend the helper project from time to time. These are usually small and unrelated projects, and I am the only person working on all of them.

I tried two approaches for using it

  • add .cs files directly (Add as link) to each project where I use them
  • compile it as .dll and add it as reference

I see some benefits and drawbacks of these approaches.
The first one:

  • is simpler, because the helper classes get compiled into the exe file, therefore I can often very easily provide just a single .exe file that will work just fine. Because I add as link, I can be pretty sure that whenever I build any project that uses the helper, the helper files will be the latest version.
  • is even simpler, because I can separate the files, so that my extension methods that run fine on .NET 4.0 can be referenced separately from the ones that require .NET 4.5, which means that the app as a whole can run on .NET 4.0
  • Allows to debug through the code, with all the benefits of breakpoints etc etc…
  • doesn't seem to be 'best practice'

The second one:

  • appears to be the right approach, but:
  • requires me to deliver a separate .dll file, which for some reason is much more difficult for users (they tend to share my programs without the .dll, which then crashes on startup)
  • as it gets compiled into a single .dll, it will require the highest version of .NET – many of my users don't have .NET 4.5 and only some elements of my helper class require this, which means I can be forcing some people to update their systems for no reason
  • I also need to make sure that whenever I update any of my programs, I also deliver the .dll file – even though I don't know if it has been changed since the last version, or not (it could have been, but it could as well be the same version). I cannot see a simple way to determine that, without keeping track of assembly version, which is additional work. For now, when I update my programs, I only deliver updated exe, and I like to keep it small and low profile.

So, what is the actual benefit for using the .dll file here? Please note, that I am the only person editing code of all the applications and the helper files.

Also, to clarify – the apps are usually very little, whereas the code contained in the helper classes is completely generic to all of them (some simple string-comparison, paths or XML operations etc)

Actually, someone made me realize just now that there's a third option.
As I have the helper code in a separte project, I can add this project to solutions of each of my separate applications – which works kind of like 'Add as link' for single files, except I only add a single project…
But as noticed by Doc Brown, this essentially means that .dll will need to be added to the project anyway…

Yet another thing which is kind of in favour of not using the dll files is the ability to debug through the helper class actively…

Best Answer

You already spotted most of the pros and cons. Using cs files as references is indeed more lightweight and often easier to manage. However, I recommend to use this approach exclusively when your cs files are fully self-contained and do not have any special build requirements.

Using separate DLLs

  • will make dependencies to other utilities or libraries explicit (so as long as you do not have such dependencies, it will work fine)

  • will allow you to define specific build configurations (for example, if a class only works in x86 configuration, or needs at least .NET 4.0, the build configuration of the assembly makes this requirement explicit).

So especially if you have lots of single-class, self contained components, using reference to files is fine, but if you have components referencing other components, or specific build requirements, I would recommend to use DLLs.

To mitigate the problems with managing many separate DLLs, you can either create an installer package, or utilize ILMerge, which can embed a set of assemblies into a single executable. In our environment, we deal with the problem differently, by using a deploy script for each application. This script makes sure all needed DLLs are always delivered to production when a new application release is published.

Related Topic