Third party libraries in an open-source C# project

Question

I'm going to start an open source project from scratch, using git (via github) to manage the source. The project will be written in C# and will depend on at least two external libraries (more are likely to come). I wonder how I should reference the libraries, and the following ideas came to my mind:

• A folder within the project that contains all external libraries as dll
  This would mean I have the dll files in my repo, which I think is bad, because it isn't source. Also, I don't know how Visual Studio (or other IDEs) store the path the libraries, if they use absolute paths, that would be impossible.

• Get the external libraries via nuget
  This would be a clean and nice way to have the libraries organized, but what what if a library I need doesn't have a nuget-package? I can't just create one, can I?

• Storing the source of the external library as part of my repo
  Sounds like a stupid idea, it would make updating the libraries a pain.

• Reference the repositories of the other projects via git somehow.
  Sounds good, I could make my own fork of it to keep a state or just point to a commit. But is that even possible? Is that a good way?

tl;dr: How should I handle external libraries in an open-source C# project?

Answer 1

If nuget is not available, the cleanest way may be to provide an export script which pulls the source code of the needed library from their external repository (of the library vendor) into your working directory. This will work even if the SCC system of the external libs is different from Git (as long as it has a command-line interface). EDIT: this will work also when the source code is not available in an SCC system at all, just as ftp or http download, for example.

You can integrate that script into your build process, of course. When using Visual Studio, as you mentioned it, you can write either a classic Makefile (using NMake), or use MSBuild to call that script when the external lib is not in your working dir. Perhaps the most simple approach is to add that script to a prebuild event, the details depend much on how the rest of your build process is organized.

Answer 2

I suspect I may get downvoted for this, but I wanted to throw this out there anyway.

I think including the DLLs themselves is really not a bad idea.

Sure, they aren't text; but that is true of plenty of asset types that commonly are included in source repositories (e.g., images).

Sure, you can't really diff them; but that is true of other compiled resources that are also often included in repositories (e.g., minified & compressed JavaScript files).

Generally speaking, they shouldn't be very large (I seldom see DLLs that are more than a Mb or two); so bloating your repo and making it annoying to clone shouldn't be an issue, either.

I recognize that NuGet is the de facto standard for managing external dependencies in .NET. However, in the event that a NuGet package isn't available for the library you want to use, I really think including the DLL is the least painful approach, without any seriously awful drawbacks that I can see.

This is assuming you are not going to frequently update these DLLs (i.e., they're libraries that have reached maturity, and release new versions on an infrequent basis at most). In this case the folder containing the DLLs is very much a snapshot of your dependencies at any point in history. When you update your dependency, you can just update the DLL.

If, on the other hand, these are libraries that are changing very frequently (e.g., they're your own libraries which you're working on in parallel with this project), then I take back everything I just said. You don't want to clutter your Git history with constant DLL updates. In this case I would actually suggest learning more about Git submodules, or using Doc Brown's script idea.