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

Question

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...

Answer 1

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.

Answer 2

DLLs are handy when an application is large and there are pieces that require updates, but not the entire application. So, if you're writing MS Word, it's handy to have the spell-check code in a DLL that can be updated without having to update the entirety of MS Word. If what you're writing is a small utility app (or a series of self-contained apps that happen to all use the same code) it doesn't make much difference whether the code is embedded in the app(s) or not.

Answer 3

You have pretty much summed it up in your question, I only have a couple of points to add.

Mono Options is a great example of a NuGet package that uses the first approach very well.

Alternatively, if you decide to use dlls you can use tools like Costura to embed that reference in your executable as an embedded resource. To use it just add the Costura.Fody package:

Install-Package Costura.Fody

Answer 4

Whether a dll is more beneficial or not depends on several factors:

1. The size of the code (when compiled).
2. How many exes use it.
3. How often you intend to update the code.
4. Whether or not the exes are intended to be kept together or exist completely seperately.

The purpose of a shared library is to take code that is common to multiple executables and centralise it so that all executables share a copy. This is intended to save space and make code easier to update.

If the amount of code in your helper class is very small, it may not be worth moving it to a dll as the overhead of the code being in a dll may counteract the space saving benefit of having it centralised.

Additionally, if you're only making a few executables, the size of the code in each executable may be small enough to not be an issue. However, the more executables you have using the same code, the more beneficial it would be to have the code moved into a dll.

As a simplified example, say your helper class compiles to 128 bytes in an exe file, but when moved to a dll, the dll is 512 bytes. If you only have 3 executables, you would be saving space by including the code in the executables. However if you had 5 executables, you would then be at the point where you would be better off having a dll because the combined space taken up by 5 copies of the code (5 * 128 = 640 bytes) is more than the space taken up by having the code in a dll (512 bytes).

Now say for example you find a bug in your helper code. If you compiled all your executables with the code baked in, you have to recompile every single executable and then redistribute the recompiled versions. If you compiled the code to a dll, you would only have to recompile and redistribute the one dll, and the bug would automagically be fixed for all of the executables using it.

Lastly, for a program to find a dll it has to know where to look for the dll. If you are keeping all your executables together, you can just put the dll in the same directory and they'll all find it straight away. If you're intentionally keeping them separated, it becomes harder to coordinate them to use the same dll.

Answer 5

Your third option is the most appropriate (add it as a separate "class library" project to the solution). This combines the benefits of all approaches:

• Your "helper project" is always up to date on all different projects.
• You can reference the code of the project when you want to quickly see changes.
• You can build it for the correct .NET version each time.
• You can embed a DLL in an exe anyway, so don't worry about that you can just have that as part of your build.

We do this all the time and I can't do anything but recommend this approach.

Another fourth alternative you have not mentioned is to put it on a private NuGet repository which would let you version it correctly and reference it without the extra project in each solution.

Answer 6

As a developer, I always like to include the reference of utility's solution to my application as it allows me debug the code (and spot possible bugs in Utility too!) plus any changes made to the utility are automatically included in the application.

So, actually the decision depends on how mature the Utility is! If you are uncertain about the Utility bugs, then you should always include the .cs file of that utility to find out the bugs.. But if you are sure that Utility is mature enough and it will not be returning result with any bugs and there is no scope for enhancement in the Utility, you can go ahead and include the DLL file.