Take the 2-minute tour ×

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?

share|improve this question

1 Answer 1

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.

share|improve this answer

Your Answer


