8

I'm building a C# library and have some dependencies through NuGet packages. I'm trying to minimise entry barrier and using the very early versions of dependency packages. For example I use Newtonsoft.Json of v6.0.1, but current version is v9x.

This is for cases when people install my package, but don't have the latest version of Json.Net - not to force them to update their references. This works, but I don't really like it - I have to work with outdated library version. And for the cases when people actually do have latest version, they are forced to add bindingRedirect into their app.config or web.config.

Is there a better way to deal with versioning hell? I'm hoping for some magic where I can say "compile me this code, include this dependent library, but ignore the version number". Is this possible?

2 Answers 2

5

There is no versioning hell. This is specifically the goal of NuGet: the different versions of the same package can be installed side by side. The only limitation is that you can't reference different versions in the same project. But what versions of libraries are referenced by the packages I depend on are irrelevant for my project.

In most cases, you can't even avoid this situation if you use third-party libraries. Imagine you depend on third-party library A and third-party library B. The A library uses a specific version of Json.Net. The B library uses another version. What do you do? Do you ask the author of one of those libraries to upgrade or downgrade the dependencies? Do you throw one of the libraries and spend the next two years rewriting it just to use a specific version of Json.Net?

As an author of a library, you shouldn't care about the version of Json.Net your customers use in their projects, or about the versions of Json.Net used by third-party libraries, because you won't get it right anyway. One customer will use the version 6; another—version 8. Your library will be installed side by side with other libraries using version 7 and the ones using version 9.

This is for cases when people install my package, but don't have the latest version of Json.Net - not to force them to update their references.

This works in a rare case of people who are using the 6.0.1 version of the library. And fails for everyone who uses the version 6.0.0. And 5.*. And 4.*. And 6.0.2. And 6.0.3. You get the picture.

The only thing you should care of is the image you give of your project. If you're using an outdated version, people could think:

Ew, this looks old. Why is this guy using a library which is not used any longer for the last three years? I think he just doesn't maintain his project any longer. I'll try one which is actually maintained.

On the other hand, if you're using the most recent version of a third-party library, what could happen? The person could find that your library is using a newer version, and decide to update her own project. Or continue using the old version, because this too is a valid choice.

8
  • I'm not concerned with argument "this looks old and not maintained". As for support version above 6.0.1 - this is where bindingRedirect will come into play. As for forcing people updating their dependencies - that's exactly what I would like to avoid. I've been in position when I could not update (blocked upstream) to next major release of a library, but a new dependency required the next version - that was version hell. And apart from Json.Net I do take some popular packages as dependencies (Autofac) where update to a latest version can be problematic.
    – trailmax
    Nov 18, 2016 at 0:34
  • I don't understand. People installing your library will necessarily install its dependencies, would it be the version 6.0.1, or 2.0.0 or 99.123.456. Also, the fact that you are using the version X doesn't force them to use the same version through the entire project. If you use 6.0.1 and they use 5.4.3 in other projects, they don't have to update anything. So what's your actual concern? Nov 18, 2016 at 0:46
  • 2
    In my experience having different versions of the same library within the same solution always causes trouble. My concern - I don't want to force update for people, yet I don't want to work with outdated stuff myself.
    – trailmax
    Nov 18, 2016 at 0:49
  • 2
    It throws "file not found" exception when trying to load a library of a particular version, when the same named assembly already been loaded, but with another version.
    – trailmax
    Nov 18, 2016 at 0:56
  • 2
    Yes, there are many Q/A on SO about this issue. The solution - get the same version of a DLL referenced in all your projects. Yes, NuGet allows it, does not mean it actually works.
    – trailmax
    Nov 18, 2016 at 1:03
0

To follow up with my solution: I take dependency on all the latest versions of the libraries I need, NuGet package I produce specifies the dependency on the latest versions of the depending NuGet packages.

To solve the problem of older version of libraries in the client code bindingRedirect in web.config or app.config can be applied to point to whatever version of the library is installed:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="X.X.X.X" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

where X.X.X.X is the installed version of the library. Though in this case clients will need to take care when installing my NuGet so their dependencies are not getting updated.

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.