3

I'm making an open source C# library (http://github.com/eteeselink/fakethat if you must). Like is fashionable these days, I plan to spread it via NuGet.

My library depends on another library (Castle.Core). Before the NuGet days, I'd use a tool such as ILMerge to merge my library and Castle.Core into a single assembly, so that the distribution is simpler. This significantly increases the size of my assembly (from 50kb to 450kb), but it's only a single DLL, which is handy for users.

Now that there's NuGet, however, I can simply add Castle.Core as a dependency and NuGet will resolve it for my users. This has a few advantages:

  • It is simpler and less error prone for me
  • If my users use another library that depends on Castle.Core, we save disk space
  • It somehow feels more "honest" - all the hard work is done by Castle.Core, all I added is a pretty API.

There's a few disadvantages, too, however:

  • If Castle.Core somehow gets removed from NuGet, my library will stop working
  • If someone still wants to use my library without NuGet, it's a bigger hassle because multiple DLLs need to be copied around
  • If a developer looks through the list of project references, she will see some weird "Castle.Core" reference that she never remembers having added. This might be confusing.

What would you do?

1 Answer 1

3

There is at least one advantage you didn't mention:

  • If Castle is updated with a bug-fix release on NuGet, the user is going to get that updated version.

If you combine all the advantages together, I think they outweigh the disadvantages. So, I think you should just add the reference to the Castle package to your package and be done with it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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