Unable to open package dialog with "Add Library Package.."

Dec 11, 2010 at 10:04 AM
Edited Dec 11, 2010 at 10:06 AM

I receive the following error when I try to use the "Add Library Package Reference.." menu option with the new verion of NuGet.  Basically this means NuGet is unusable.

I get a similar error from the console when I try to execute Get-Package.  I have uninstalled (and deleted the NuGet directory in the VS program files directory) and reinstalled and I still have the same issue.


Get-Package : The 'minVersion' attribute is not declared.
At line:1 char:12
+ Get-Package <<<< 
    + CategoryInfo          : NotSpecified: (:) [Get-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGet.VisualStudio.Cmdlets.GetPackageCmdlet


Microsoft Visual Studio
The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.


1) The 'minVersion' attribute is not declared.


Resulting in: An exception occurred while trying to create an instance of type 'NuGet.Dialog.PackageManagerUI.PackageManagerWindow'.


Resulting in: Cannot activate part 'NuGet.Dialog.PackageManagerUI.PackageManagerWindow'.

Element: NuGet.Dialog.PackageManagerUI.PackageManagerWindow -->  NuGet.Dialog.PackageManagerUI.PackageManagerWindow -->  AssemblyCatalog (Assembly="NuGet.Dialog, Version=1.0.10128.89, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")


Resulting in: Cannot get export 'NuGet.Dialog.PackageManagerUI.PackageManagerWindow (ContractName="NuGet.Dialog.PackageManagerUI.PackageManagerWindow")' from part 'NuGet.Dialog.PackageManagerUI.PackageManagerWindow'.

Element: NuGet.Dialog.PackageManagerUI.PackageManagerWindow (ContractName="NuGet.Dialog.PackageManagerUI.PackageManagerWindow") -->  NuGet.Dialog.PackageManagerUI.PackageManagerWindow -->  AssemblyCatalog (Assembly="NuGet.Dialog, Version=1.0.10128.89, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")


Dec 11, 2010 at 10:49 AM

Does this happen if you use a brand new project? Did you have old packages installed previously? If yes, what was installed before?

Dec 11, 2010 at 9:35 PM

I'm experiencing the same problem.

Everything works fine on a new project but when attempting to launch the package manager window on an existing project (with existing package references) I get the same error above.

On the last nuget upgrade I ended up having to remove all my package references and re-add them. I hope I don't have to the same this time.



Dec 11, 2010 at 10:21 PM

What packages do you have installed? We made a very small breaking  change to the nuspec format. minVersion is no longer valid for dependencies.

Dec 11, 2010 at 10:31 PM

Here are the packages that I have:

  <package id="Castle.Core" version="2.5.1" />
  <package id="Castle.Windsor" version="2.5.1" />
  <package id="MicrosoftWebMvc" version="2.0" />
  <package id="MvcContrib" version="" />
  <package id="T4MVC" version="2.6.30" />
  <package id="AutoMapper" version="" />
  <package id="elmah" version="1.1" />
  <package id="Rx-Core" version="1.0.2787.0" />
  <package id="Rx-Main" version="1.0.2787.0" />

Dec 11, 2010 at 10:36 PM

And mine:

  <package id="structuremap" version="" />
  <package id="log4net" version="1.2.10" />
  <package id="microsoft-web-helpers" version="1.0" />
  <package id="SQLCE" version="4.0.8435.1" />
  <package id="EFCTP4" version="1.0" />
  <package id="WebActivator" version="" />
  <package id="SQLCE.EntityFramework" version="4.0.8402.1" />
  <package id="elmah" version="1.1" />
  <package id="NUnit" version="" />
  <package id="RhinoMocks" version="3.6" />


Dec 11, 2010 at 10:58 PM

So, MvcContrib has the culprit for me.  I delete that and now I can update packages and delete packages.

But it looks like the NuGet feed is not working now.  I cannot see any packages in the Online section.

Dec 11, 2010 at 11:37 PM


What url is the nuget feed pointing to?


You'd need to look at the nuspec inside of the packages you have installed in the packages/ folder and see which one has the minVersion attribute.

If alot of people run into this I'll write a tool to fix-up local repositories.

Dec 12, 2010 at 4:37 AM

Indeed, MvcContrib had MinVersion on the ctp2 feed up until 3 weeks ago, so if you installed before that you'd have the issue.

But @RobCannon's empty package list issue should not happen, so we indeed need to look at what feed your client in pointing to.

Dec 12, 2010 at 9:10 AM

The problem package was EF CTP4 which I have now removed and am now going through the painful process of upgrading my app to CTP5.



Dec 12, 2010 at 1:34 PM

The feed I am using it http://go.microsoft.com/fwlink/?LinkID=204820

I double checked it with the nuget website...

Dec 12, 2010 at 6:47 PM

Your feed should have been updated when you installed the update to NuGet. This is the new fwlink: http://go.microsoft.com/fwlink/?LinkID=206669

Dec 12, 2010 at 8:11 PM

I see, our 1.0 release notes were still pointing to the old feed.  I have just corrected it.  Sorry for the confusion!

Dec 12, 2010 at 9:13 PM

That was it.  Everything is good now, thanks!

Dec 13, 2010 at 9:53 AM

I'm having the same problem... the culprit for me is mongo-csharp-driver

Dec 13, 2010 at 4:00 PM

Can you confirm that the spec format only supports exact version now, but the format in the feed still has min/max?

Dec 13, 2010 at 4:18 PM
Edited Dec 13, 2010 at 4:40 PM

We're a bit behind on docs but that will all change this week. Here's a quick summary of the changes:

For dependencies, the nuspec supports the version attribute and expects a version spec, described here.

Dependencies are in the feed are separated by | and are in the format id:versionspec.

Note: By default the nuspec's dependency version="x.x" is equivalent to "[x.x,)" i.e., min version is the default if no special syntax is used.

Hope that helps.

Dec 13, 2010 at 5:28 PM

Having a look, the previous feeds had dependency:min:max:exact, separated by comas, with each component spearated by a semicolumn, even present when the value is not there.


Are you saying this has changed to have dependencies spearated by |, and containing the min, with max and exact being optional *and* the semicolumn now being optional too?


Dec 13, 2010 at 5:33 PM

Did you look at this page?  It has all the details on what versionspecs look like (which is a subset of the Maven syntax).  We don't use semi-columns.

Dec 13, 2010 at 5:38 PM

Maybe some examples will clear it up:

  1. A:1.0 -> A >= 1.0
  2. A:1.0|B:[2.4, 5.0)  -> A >= 1.0, B >= 2.4 && B < 5.0 
  3. C:[1.0] -> C = 1.0

dependency:version spec

Dec 13, 2010 at 8:43 PM

I'm sorry, I realize I'm probably being very thick david, but I see semicolumns in your feed format. I see "<Dependencies>Name:Version</Depednencies> and version doesn't have any of the maven-style dsl in them. Are you saying that you will be supporting those in that field, instead of the CTP2 format of dependency:min:max:exact ?

Dec 13, 2010 at 10:21 PM

For now I assume it is what you meant.

So am I right in understanding that you only default A:1.0 to A >= 1.0, but C:[1.0.0] will mean 1.0.0 and not 1.0.1?

Dec 13, 2010 at 10:33 PM

Oh, those are colons, not semicolons.  I think that's the misunderstanding :)

Yes, your understanding is correct.  Currently nothing on our feed uses anything but the plain A:1.0 syntax, but it is supported.

Dec 14, 2010 at 12:58 AM

colons. Kk.

So A:1.0.0 means >= 1.0 and A:[1.0.0] means == 1.0.0? What do you do with the revision then?

Dec 14, 2010 at 7:08 AM

Revisions work the same way.  e.g. A: means >=, and A:[] means ==  Of course in practice, it's best not to include those in the dependency spec.

Dec 14, 2010 at 10:05 AM

so by default you always ignore build and revision when the dependency is not a range, but never ignore any component if the dependency is a range. That means the only way to get patches is to specify no range at all, in which case you only support patching or version ranges, correct?

Dec 14, 2010 at 4:18 PM

Not quite.  There are two phases to the resolution:

  1. Find all the packages that are in the specify range. Here, there is no special casing of the last two numbers
  2. Select a package among those. Here we select the package with the lowest version (first two numbers), but the highest Build/Revision.

Let's take a complete example:

  • The range is [,
  • The feed has 0.5,,,,,,,,,,

Here we have:

  • Phase 1: the packages that are in range are:,,,,,
  • Phase 2: within those, the packages that have the lowest Major/Minor version are,,, We pick the highest of those, so


Dec 14, 2010 at 4:49 PM

Ok, so the first phase is the normative rules for package ranges, and that's the only thing I'm interested in, as our resolver does the opposite as yours, which is fine as we have version levelling implemented.

So from what I  understand, you respect during resolution the contract that the package manager has given, and you then make a choice as to which of those valid versions you'll include, whatever that choice may be.

To conclude, am I right in understanding that the behavior you describe where the version is specified as "2.1.0" does mean "at a minimum 2.1.0 and anything above" as far as the package is concerned, and that the auto-upgrade feature that has been talked about on build/revision only concerns those packages that respect the specification? That's what I now understand from your explanation, hopefully this time around I'll have it right.

Dec 14, 2010 at 4:53 PM

Yes, that sounds correct. "2.1.0" is just a short form for "[2.1.0,)".

Dec 14, 2010 at 7:17 PM

So am I correct to say that this bug http://nuget.codeplex.com/workitem/336 is by design?

Dec 14, 2010 at 7:50 PM

I think you linked to the wrong bug.

Dec 14, 2010 at 7:54 PM

No, it's not the wrong bug. Watch the Drew's video attachement to see what I meant to ask.

Dec 14, 2010 at 8:11 PM

I'm not sure that bug is by design. I think there's a caveat to the rule David outlined that we need to clarify. There should be a phase 1.5.

  • Phase 1: the packages that are in range are:,,,,,
  • Phase 1.5: If there's already a package installed within that range, we should not continue to install that package.
  • Phase 2: within those, the packages that have the lowest Major/Minor version are,,, We pick the highest of those, so

Does that make sense?

In other words, if a package within the candidate package version range is already installed, the dependency is satisfied and we shouldn't try to install that dependency.

Dec 14, 2010 at 8:38 PM

I'd say that if the license hasn't changed, then an automatic update is not necessarily a problem. We auto-update to the latest version and depend on pacakges doing the right thing when it comes to specifying their versioning, and rollback in case of failure.

Dec 14, 2010 at 8:43 PM

@haacked: agreed about your phase 1.5.  I *think* it works this way already, but I'll let fowler verify.

We should move some of those examples to the doc.

Dec 14, 2010 at 11:29 PM

OK, that makes sense.

Dec 16, 2010 at 11:18 PM

Ok, I captured these rules in the following doc: http://nuget.codeplex.com/wikipage?title=Dependency%20Resolution

Note that this page shows current behavior as well as proposed future behavior. I also updated the section on package leveling as I realized there's a couple ways we can do leveling.

Dec 17, 2010 at 12:48 PM

Ok, so I'm revisiting the subject once more, about the defaulting to v <= x. It breaks badly for current packages in your feed.

Take fluent nhibernate, it defines a dependency on nhibernate 2.1.4000, without ranges. As per your spec, OpenWrap correctly goes and upgrades to 3.0, which breaks everything.

I'd suggest one of the following resolutions:

1. Fix all the package definitions in the current feed to be exact ranges

2. Revert the default to assume strict equality, maybe only on major.minor (so = would mean = 2.1)

3. define that the default means minimum, with a maximum autogenerated to exclude major or major.minor revision (so would translage to <= x < 2.2 or < 3)

One of those needs to be done, otherwise we can't process the packages existing in the nuget feeds. Again, it's very important to make the distinction between the normative version ranges in package definitions, and the manager's specific behavior which may change based on the resolver. Many managers indeed do include multiple resolvers, and they need to work off a clear set of ranges, and make decisions within those valid ranges.

Dec 17, 2010 at 4:45 PM

Based on our rules, if you install FluentNH, it will install NH.Core and nothing is broken.

Dec 17, 2010 at 6:27 PM


Let me repeat again, you may have missed the core of the argument. The default for dependencies leads to choices that are valid but broken. The fact that the current behavior of your pacakge resolution mechanism somehow makes this invalid default work is an implementation detail of what you do with the range specification.

I happen to implement a different algorithm to resolve pacakges after the incompatible packages per the spec have been removed. As such, the behavior exhibited by OpenWrap is perfectly valid as per the intent of the author.

It is not unreasonable as such for me to ask you to remove from your analysis your implementation details or this will lead not only to breaking OpenWrap, but also will prevent you very much from changing the resolution behaviour in the future.

Dec 17, 2010 at 6:39 PM

Sorry, I'm not following you at all here.  Our dependency resolution algorithm generally just does the right thing, and it was fine tuned over time to achieve this.  In your previous mail, you brought up a case where you thought the algorithm would do the wrong thing, but that was based on your misunderstanding of the algorithm, since the version you claimed it would install is not the one that it would.

Do you have a specific scenario where our algorithm doesn't do the right thing?  If so, I would be happy to discuss.

Dec 17, 2010 at 6:59 PM

Your algorithm is not important. Your feed or your default is problematic. I'll repeat once more, maybe this time my choice of words will make it more apparent what is broken.

Your default feed does not include range of versions.

Your range specification (not the description of your algorithm, that's your algorithm, not the specification of versions, your algorithm is not the normative range of versions that are allowed, it is one way of choosing when multiple allowed versions are available), and by range specification I mean the maven-style table that people write in their <dependency> tags, or that are included in your feed in the aggregated <m:Dependencies>, but not the content of your algorithm or it's description, that range specification says that in the absence of a range, it defaults to more than or equal.

This, in the case of your current feed, aka the atom-formatted, odata-supporting resource (and by resource i mean a thing that has a web address) existing at http://feed.nuget.org/rtm/odata/v1/Packages, you will see that ranges are not specified.

Hence, your system currently says that every single of those packages are compatible with any of the dependencies described, *or any above*. This is the contract that is visible and part of your package format and feed.

Hence fluent nhibernate 1.1 is, *according to your feed* and according to the package, compatible with nhibernate 3.0, because that is what is declared by your system.

The fact that your algorithm can auto-correct deficiencies in the range descriptions, either the ones introduced by the package authors, or the ones by the flawed specification (and by specification I mean the maven-style stuff, and by flawed I mean it doesn't work, right now, on your current feed, for it doesn't provide defaults that are valid, and by valid I mean according to dependency versioning ranges, not the details of the algorithm that is an impelmentation detail of your package resolver, see above), doesn't make it acceptable to say that there is no problem.

Let me rephrase once more what choices are available to you to fix those broken things (and by things I mean all that I just typed).

  1. You can either fix all the dependency versions in your feed to reflect the fact that some if not all were authored for exact versions, and verify indeed that they provide invalid versions. Of course I could start a long march to go talk to every package author for them to resubmit them, but after all it's your server, not mine. Those packages have invalid dependencies at the moment.
  2. Or, you can change what the lack of identifier means to mean something else than "anything above what was written there". See above for details, i'm pretty sure those ones are clear enough to stand on their own.

I can't be more clear than that. Be it that your packages or your spec or both are broken, they are, they break a different package manager that processes the information in your packages accurately.

Alternatively, we'll just have to change what the defaults for nuget pacakges do to be incompatible with your specification, to account for the existence of those problems.


Dec 17, 2010 at 7:21 PM
We've been very clear all akin that our feed is a test feed. Once the gallery is available, we'll encourage package owners to take ownership of their packages. This is pretty much inline with #1 you proposed below.

At this point, we're done with v1 of NuGet and are startin on 1.1. So we can't change the default now. We have other teams who depend on NuGet core and we can't reset them.

Seb, we didn't chose this default just to spite you or "be evil" as you stated on twitter. Such mean spirited hyperbolic statements don't really help anyone and only serve to stifle discussion.

Dec 17, 2010 at 7:27 PM
Edited Dec 17, 2010 at 7:30 PM

I requested you guys to not be evil and fix what can be fixed. Right now OpenWrap users cannot use nuget pacakges anymore, and David replies by saying there is no problem. The default leads to invalid states which are breaking other people, and that's the sitaution we're in, I don't believe that "encouraging pacakge owners" to do anything is going to help fix what is the statement your spec makes, aka that "If you define that v1 is compatible, then surely v20 will be too, so thats what we default on". It doesn't even reflect the more conservative resolution algorithm you have published! And as you can't change your feed until your "gallery" is online apparently, then it leaves me with a b0rked nuget support.

If those kind of changes and discussions were done in concertation beforehandl, then there wouldn't be a need for all the noise. I'm tired of having been the only side of this equation to outreach to keep compat. I wish things had been and were different. But that's a very separate conversation to be settled through different channels.

The default doesn't make sense and doesn't reflect the spirit behind your algorithm. So if you are happy with that, then I will go and change the versioning rules for nuget feeds to implement something saner, aka that the default of x.y.a.b will now be, for nuget packges only, equivalent to >= x.y and < x.y+1


Dec 17, 2010 at 7:39 PM

The choice to only specify a min version on most packages was entirely deliberate, and will likely not change (unless we find fundamental issues, which so far we have not).  Package authors can choose to add a closed range, but leaving it as a min range will be the general guidance, as it allows the most flexibility.

Note that I don't think the feed range information should be decoupled from resolution algorithm.  The feed is designed to work well with a specific algorithm, and we will not change that algorithm once it is stable.

So for the feed to be usable by alternate clients like OW, those clients may need to use an adapter that allows packages coming from the nuget feed to be handled using rules that are expected for the feed.

As an aside, take a look at rubygems.  Most of their dependencies only specify a lower bound.


Dec 17, 2010 at 7:42 PM

I’m aware of the rubygems dependencies. Look at other package managers and how they function when declaring package ranges. When I started working on this problem nearly a year ago, I looked at lots of package manager.

One thing definitions do is to *decouple* algorithm behaviour from definition. But I don’t want to repeat myself again, it’s obviously not useful.

From: davidebbo [email removed]
Sent: 17 December 2010 20:39
To: Sebastien Lambla
Subject: Re: Unable to open package dialog with "Add Library Package.." [nuget:237992]

From: davidebbo

The choice to only specify a min version on most packages was entirely deliberate, and will likely not change (unless we find fundamental issues, which so far we have not). Package authors can choose to add a closed range, but leaving it as a min range will be the general guidance, as it allows the most flexibility.

Note that I don't think the feed range information should be decoupled from resolution algorithm. The feed is designed to work well with a specific algorithm, and we will not change that algorithm once it is stable.

So for the feed to be usable by alternate clients like OW, those clients may need to use an adapter that allows packages coming from the nuget feed to be handled using rules that are expected for the feed.

As an aside, take a look at rubygems. Most of their dependencies only specify a lower bound.

Dec 17, 2010 at 10:39 PM

@davidebbo, so you're saying that if a package maintainer (PM) sets a dependency version="1.0.0" that we are treating it as compatible with ALL versions from 1.0 and up?

That seems like a dangerous default, and something I don't believe PMs would expect.

I thought we were going to use the SemVer model where versions are scoped by the MAJOR number. That is, 1.0 is compatible with 1.0, 1.1, 1.n all the way up to but NOT including 2.0. The assumption is that incrementing the MAJOR version may contain breaking changes.

I think a PM should have to explicitly specify which MAJOR versions they are compatible with. 

So let's say I'm the PM for package foo, and I have dependency bar, version="1.0" which SHOULD BE equivalent to [1.0,2.0).

If bar v2.0 comes out, we won't automatically pull updates to it since it's a MAJOR version bump and we should NOT implicitly update MAJOR versions.

Now as PM, I test bar 2.0 and see that it's still compatible, just has some new features. So I update my package bar and set the dependency foo version="[1.0,3.0)"

NOTE: I used the Maven syntax, although I wish it was a simple as version="1.0+, 2.0+"

BTW: Here's some discussion regarding versioning dependencies for Ruby Gems: http://blog.zenspider.com/2008/10/rubygems-howto-preventing-cata.html

Anyway, I'm not sure if Sebastien and I are asking for the same thing, but if the default behavior is as you say, then I think it's going to cause a lot of problems going forward.

Although this still doesn't deal with something like FluentNHibernate. Package depends on NHibernate and Package depends on NHiberate Notice the package version is only updated in the 3rd segment (PATCH/REVISION). 

This is really bad because it's going to do unexpected things. Say I'm a developer using FNH 1.1.0 and NH 2.1.2 and I'm happy. I notice that FNH has a VERY MINOR update 1.1.1, so I decide to update. Now NuGet sees it depends on NH 3.0 and makes a MAJOR upgrade to my project! WTF!?!

I believe there should be some guidelines on versioning packages for package maintainers. They really need to be aware of how updates will be applied, not only to their package, but all the dependencies as well.


Dec 17, 2010 at 11:00 PM

This is the Maven syntax.  Writing "1.0.0" is a short form for writing "[1.0.0,)".  If you want exactly 1.0.0, you can write "[1.0.0]".  So that's just syntactic sugar.  In the end, the syntax is very flexible and allows any range to be specified.  I don't want to use most of the Maven syntax, but then change the semantic of "1.0.0" to mean "[1.0.0]" instead of "[1.0.0,)".

What makes the current rules work so well is that we default to the smallest Major/Minor version.  So in your scenario, even after bar v2.0 becomes available, installing foo will still pull bar 1.0 (per rules explained above).  So even though foo says that it'll work with bigger versions, we don't go and wildly update dependencies to much newer versions unless we have to.

Of course, specifying min only may not always be right, but most often it will produce the best mix of keeping things stable and flexible.

The FluentNHibernate case you mention is in my opinion a misuse of versioning.  As you suggest, going from to should be a very minor/safe upgrade.  But the fact that the slightly newer one takes a dependency on a much newer NH, makes the FluentNH use of versions pretty bad.  The FluentNH that uses the much newer NH should have received at least a minor version bump, not just a 3rd segment.  Note that it also violates the SemVer scheme pretty badly (since a 3rd segment change is meant to be a bug fix). 

Yes, we need to improve doc and come up with clearer guideline.  But I do think the system we have set up will yield the best behavior is a large percentage of cases.