4

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?

| improve this question | |
  • For option #4, git submodule, perhaps? I've never used it and hear it's not so good in practice, though. – apsillers May 23 '13 at 16:31
  • What kind of libraries are you talking about? .Net assemblies? – Thomas May 23 '13 at 17:18
  • @Thomas: Yes. Like log4net, or other assemblies. – looper May 23 '13 at 17:56
  • VS stores references as relative path whenever it is possible (csproj files are more or less human-readable XML files, compatible with MS Build, you can use a standard text editor to open them and change the paths manually, if you like). – Doc Brown May 23 '13 at 21:00
3

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.

| improve this answer | |
  • Is there a possibility to make that automatically, so that the user who clones the repo doesn't need to execute the script, too? – looper May 23 '13 at 16:18
  • @looper: you did not read my full answer, didn't you? – Doc Brown May 23 '13 at 16:19
  • I read it, but misunderstood it. And misunderstood it again. Then, after writing this text the first time, I think I finally understood. Sorry for that :). – looper May 23 '13 at 16:21
  • @looper: I guess you will need a script which exports the lib into your working dir and runs the build stage of that lib first (for example, by calling msbuild or calling the VS-IDE from the command line). Your project can reference the DLLs and they will be ready to use when they will be needed. But as I wrote above, the details depend on your overall build process. – Doc Brown May 23 '13 at 16:42
7

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.

| improve this answer | |
  • I agree, this option maybe the best especially if the vendor provides a stable build of that DLL, and you are not going to change anything in the lib sources, and you also don't want to debug them. – Doc Brown May 23 '13 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.