Support version ranges in project.json

[ptrstpp950]

I am trying to force kpm restore for downloading latest nuget from feed. I did following steps:

1. I deleted everything under: C:\Users\[user]\.kpm\packages\Newtonsoft.Json
2. I created simple project.json file:

{
    "version": "1.0.0-*",
    "dependencies": {
        "Newtonsoft.Json":""
    },
    "commands": { 
        "run" : "run"
    },
    "frameworks" : {
        "aspnet50" : { },
        "aspnetcore50" : { 
            "dependencies": {
                "System.Console": "4.0.0-beta-*"
            }
        }
    }
}

3. I run following commands:

• kpm restore-> Newtonsoft.Json package wasn't downloaded
• kpm pack -> reports an error:

Warning: Failed to resolve the following dependencies for target framework 'Asp.Net,Version=v5.0':
   Newtonsoft.Json

Searched Locations:
  E:\projects\aspvnext-tests\{name}\project.json
  C:\Users\garat_000\.kpm\packages\{name}\{version}\{name}.nuspec
  C:\Windows\Microsoft.NET\assembly\GAC_32\{name}\{version}\{name}.dll
  C:\Windows\Microsoft.NET\assembly\GAC_MSIL\{name}\{version}\{name}.dll

Try running 'kpm restore'.

Warning: Failed to resolve the following dependencies for target framework 'Asp.NetCore,Version=v5.0':
   Newtonsoft.Json

Searched Locations:
  E:\projects\aspvnext-tests\{name}\project.json
  C:\Users\garat_000\.kpm\packages\{name}\{version}\{name}.nuspec

Try running 'kpm restore'.

Sum up
Did I do something wrong? Or project.json dependencies are fixed to version number?
I tried also using * in version number but I cannot make it work usually having error similar to below:
'6.0.*' is not a valid version string.

[Eilon]

You need to have a version number for each non-project dependency. If the dependency is a NuGet package, it must have a version number. I think the * might be allowed only for the pre-release portion of a version. I recommend using a specific version number (e.g. 6.0.6 for Json.NET) for a released version of a package.

[davidfowl]

Yes, use a specific version. There's no way to say always use the latest.

[Eilon]

Well, not yet 😄

[ptrstpp950]

If not yet, can I propose such feature? For example definition of dependency can look like:

"Newtonsoft.Json": {"useLatest":"true"}

or

"Newtonsoft.Json": {"useLatest":"true", "maxVersion":"10.2.3.4"}

Such feature is extremely useful in internal large projects. In my case we have more than 100 sln, which gives us up to 700 nuget. All of them can be produced daily (they aren't, but it is possible). Now we are using https://github.com/DarthFubuMVC/ripple which allows to specify "fixed" and "float" dependency - the concept of this is described here: http://fubuworld.com/ripple/gettingstarted/concepts/

What do you think about this?

[davidfowl]

Don't really think it's the same for external dependencies and not realistic to just use the latest all the time. However, we do something similar with our projects (ASP.NET 5 is 30+ repositories) and for that we use snapshot versions (http://stackoverflow.com/a/5901460/45091). If you take a look at any of our projects:

https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.Core/project.json#L7

You'll see that it references 1.0.0-* or 6.0.0-*. These are projects that are being built as packages. We reference the latest built version (it's similar to ripple in that way). I think this is a better way to achieve what you're going for.

That said, we will eventually support version ranges but I'd rather not conflate the 2 things.

[ptrstpp950]

The only problem with this solution is when we are using external nuget like quite popular Newtosoft.Json or Microsoft libraries.
As you probably know convention in build numbers is that last one is patch (exactly MAJOR.MINOR.PATCH), so in my opinion allowing asterisk in version number like: 6.0.* will be quite useful.

The real life case is last System.Web.MVC upgrade. Because of security MS release a new version of above package. Using your solution for prerelease version will not resolve this problem, and the manual change is needed in every single project which use this package (in our case most of sln).
Allowing "latest" version or full-asterisk version like 6.0.* (not 6.0.0-*) is much better.

The support for version ranges is in my opinion quite same, until we will force download latest version which is in range.

[davidfowl]

How often to you float dependencies against released software not under your control? Seems like the minority case and version ranges will let you at least have some control over what versions get referenced.

Just referencing the latest seems like a bad idea anyways. Especially if you jump across major versions. It's like saying you want the latest MVC which is a major breaking change from any previous MVC (basically a rewrite).

[ptrstpp950]

To continue discussion: I forgot to mention that I use self-hosted nuget gallery, which allows me to control every version which internal developers use.

To your question: "How often to you float dependencies against released software not under your control?" - maybe sound strange but quite often. Fortunately usually it is JavaScript libs, which isn't a big problem as regular dll.

Anyway I don't want to use latest MVC, but I want to use latest MVC 8.0.X , so you are right that supporting version range will resolve my problems.

So what do you think about version range support? I could try to take a look into this.

[davidfowl]

I think it's something we have to do but to be honest, I'd rather we do it as the change will be very impactful to some of the stack. I'll put this bug in the RC milestone to investigate.

[davidfowl]

We might also want to support the syntax that other package managers have:

"dependencies": {
  "Microsoft.AspNet.Mvc": "~6.0.0"
}

Which means that you want to float 3rd number.

[ptrstpp950]

But such syntax change should also have impact on nuspec version syntax, because they are representing exactly same.
Using bower syntax is cool, but you should consider relation between nuspec and KRuntime

[davidfowl]

Agreed, nuget uses the maven syntax. As long as we can translate to something nuspec likes we can use any syntax we want.

[davidfowl]

Closing this as a dupe of #442