nuget installs latest version of Rx-Main, breaks Simple.Data

Feb 12, 2011 at 7:44 PM

I've added a dependency on Rx-Main 1.0.2838 in Simple.Data's nuspec, but now the Rx team have posted an update (1.0.2856) that's the version that gets installed. Since the Rx assemblies are strongly-named/signed, my library no longer works :(

Seems to me this is another fundamental fail of the whole assembly-signing idea, but is there anything i can do about it?

Feb 12, 2011 at 7:57 PM

There are 2 things you can do. Live with it, we have a command called Add-BindingRedirects (renamed to Add-BindingRedirect in 1.1) that will the necessary add binding redirects to solve this particular problem. If you don't want users to have to do that (we're looking at ways to make this more automatic), then you can make you're dependencies a more strict version by putting [] around them:

<dependency id="Rx-Main" version="[1.0.2838]" />

If you want more details on how NuGet versioning works, David Ebbo wrote a great 3 part series:

The 3rd article is relevant to this discussion if you want to skip ahead.

Hope that helps

Feb 12, 2011 at 8:27 PM

That's brilliant, David, thank you. 

Feb 13, 2011 at 7:10 AM

Mark, what was your experience with Add-BindindingRedirect? Did it just work on the first try?

At some point, we should think about maybe doing this automatically.

Feb 13, 2011 at 12:02 PM

I didn't go with that, I'm just adding the square brackets to the nuspec file and planning on kicking up a fuss on the Rx forums about why their work isn't open-source.

Have you guys considered having an optional "build-during-install" mode for nuget, for open-source projects? Since most of the libraries on the repository are OSS, I don't suppose there'd be any issues from the developers' side. It's quite common for rubygems to build native bits from source during a gem install, which resolves all the issues around linking to specific versions of Linux libs and kernels. In this instance, it would mean Simple.Data just got whichever signed Rx assembly was current, and built against it during the package-install.

Feb 13, 2011 at 4:47 PM

We haven’t seen a big demand for that yet, but it’s something we could consider in the future. We want to focus on the binary scenario first as it seems that’s how the broader audience incorporates OSS libraries into their own projects.

But it’s not out of the question to consider as NuGet gets more mature. It’s a young product still, we’ve only been out for a month in RTM form technically. J

Feb 13, 2011 at 5:06 PM

The other problem is that 1.0.2838 is no longer available, looks like it was replaced with 1.0.2856. Surely removing a version of a package from the repository is a very bad thing to do? If both versions were available it wouldn't have screwed up all of the packages that depend on 1.0.2838.

Feb 13, 2011 at 5:11 PM

Agreed. We may need to look at potentially not allowing fully removing packages from the gallery and only supporting “yanking” them.

Feb 13, 2011 at 7:44 PM

Please read my posts on this topic (links above), as it will help get on the same page around this.

We need to be clear about what we mean when we talk about things being broken. It could mean 3 entirely different things:

  1. The packages that use the old version fail to install because of the missing dependency: if you are seeing this, then you are probably using NuGet 1.0, as with 1.1, it will automatically get you 1.0.2856 instead of 1.0.2838.
  2. The packages install fine, but things fail at runtime because of the mismatched version: here you simply need to call 'Add-BindingRedirect' to unify things. As I mentioned above, we should look into make this more automatic.
  3. Things fail at runtime, even after adding the binding redirect: that would seem to imply that there were some breaking changes between 1.0.2856 and 1.0.2838, which should not happen with proper versioning (since only the third number was increased).

Can you please clarify which of these 3 situation you're running into (or maybe yet some other thing)?

Mark, the problem with using [1.0.2856] is that it leads to upgrade hell. e.g. Suppose some other package Foo asks for the newer 1.0.2655, and someone wants to use both Simple.Data and Foo in the same app. This would be completely impossible, since no unification would be allowed.

Again, please make sure to read my posts as there is a lot of information about this. I'm not saying that everything there is correct, and we're always open to changes, but it will make for a better discussion if we've all read it :)

Feb 13, 2011 at 8:05 PM

Hi David,

I've added your posts to my InstaPaper queue, but in the meantime I think we're talking about case 3 here; the Rx releases are always 1.0.x and often have breaking changes.


Feb 13, 2011 at 8:59 PM
Edited Feb 13, 2011 at 8:59 PM

There might be breaking changes, but it only matters if it an API that you were using has changed. 

Feb 14, 2011 at 6:12 AM

Right, that's a point I try to make in part 2 of my series, in the 'Backward compatibility is in the eye of the consumer' section.

That being said, it's entirely possible that Rx did have changes that actually broke Simple.Data, and that is unfortunate. We should discuss with the Rx folks.