When creating NuGet packages, how do you define your dependencies?
If you’re using the default setting of ‘x’ version or newer are you sure that all future versions of the dependency will work with the current version of your code? I’m not sure many people would be happy saying yes to that question but most NuGet packages are deployed with the default setting for their dependencies. Using a typical dependency, Log4Net, you might deploy a package today referencing the current build and everything’s fine. But in a month or two’s time, there may be an update to Log4Net deployed that contains breaking changes. From that point on anyone that grabs your package from NuGet will find that it no longer works – instead of the version of Log4Net you developed against, they are now getting the latest version that breaks your code.
Whilst it may be more work, the safer option may be to use the version “range” option for managing dependencies; only including versions that have been safety tested and are known to work with your codebase. It may be more work, requiring you to retest and update your package each time a dependency is updated but your users will thank you for it.
Update
Since writing this blog post a breaking change has been published to NuGet for the very well used log4Net package. Phil Haacks blog post covers the issue in creating detail and I won’t attempt to recover it here but it does highlight the risks associated with being fully dependent one or more 3rd parties – your code (and therefore your consumer’s code) may fail because a dependency has been incorrectly versioned/deployed. In his article Phil also links to an interesting set of posts on how NuGet handles the package versioning.
As part of his fantastic ‘What is .NET standard‘ presentation at DDD12, Adam Ralph provided an amazing amount of detail in such a short amount of time. One of the most valuable points, which is completely obvious when you think about it, is how you should work with .NET standard when creating libraries. NET standard now comes in a multitude of flavours: currently 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 and 2.0. When starting out . . .
If you’re trying to access a class library (.NET Standard) from a traditional console application (in VS2017 those can be found under ‘Windows Classic Desktop’) you will run into problems; which can feel a little strange for something that was pretty simple in VS2015 and earlier. You can add a reference to the class library project (Resharper will even volunteer to add the dependency / namespace reference if you don’t already have it). But the . . .