Dependencies similar to Binding redirects about unitynuget

[xoofx]

So, by what you say @xoofx you mean doing something along the lines of:

I thought about something maybe slightly simpler, that would require no changes in registry (kind of an implicit/transparent/automatic override):
If a Package A has a dependency to Package B v1.0 (that is not yet netstandard2.0), but Package B only provides netstandard2.0 starting at v1.1, then we implicitly upgrade the dependency of Package A to B to v1.1 (we statically resolve the dependency >= v1.0 at startup time). The Package A would then say in its dependencies description that it really depends on v1.1.

What do you think?

So thanks for that @xoofx and good luck with all the work you have together with @joshpeterson and the rest of the team to bring us the best of the .NET ecosystem.

Thank you also for helping UnityNuGet, you brought most of the changes to it in the past year and that's super welcome if it can help lots of folks around! 👍
But agreed, we are all eager to move to CoreCLR and MSBuild SDK project.

[bdovaz]

Yes. (a different way to express it is (we statically resolve the dependency >= v1.0 at startup time))

👍

Hm, not sure to understand. When I look at NuGet protobuf-net, the version 2.3.6 supports netstandard 2.0, so why do you need to only register a 3.0.0 version?

Ok, sorry, you're right. I was fixated on 3.0.0 because of the fact that it depends on several System.* packages in 4.3.0 that do not target .netstandard2.0 but what we are talking about would turn the 2.3.6 version of protobuf-net into (upm manifest example):

{
  "name": "protobuf-net",
  "version": "2.3.6",
  "dependencies": {
    "system.reflection.emit": "4.6.0", // Originally 4.3.0.
    "System.Reflection.Emit.ILGeneration": "4.6.0", // Originally 4.3.0
    [...]
 }
}

Once this PR is done we can take a look at all the entries in the registry.json file that have an "incorrect" minimum version since they do not point to the older version that targets .netstandard2.0 but to the minimum version where all its dependency chain complies with .netstandard2.0 targeting.

[xoofx]

@xoofx How did you build this listing, i.e. where did you get it from? I need another one for .netstandard2.0:

Check the content of the NuGet package https://www.nuget.org/packages/NETStandard.Library/2.0.3 in the sub folder build\netstandard2.0\ref and you will get the list of assemblies part of netstandard2.0

[bdovaz]

I have several doubts that you can solve.

I am going to represent it with the same case that we have been given of protobuf-net and I am going to put the minimum versions that support .NET Standard 2.0 (the example of the first post):

{
    "protobuf-net": {
        "listed": true,
        "version": "3.0.0"
    },
    "protobuf-net.Core": {
        "listed": true,
        "version": "3.0.0"
    },
    "protobuf-net.Grpc": {
        "listed": true,
        "version": "1.0.0"
    }
}

If a Package A has a dependency to Package B v1.0 (that is not yet netstandard2.0), but Package B only provides netstandard2.0 starting at v1.1, then we implicitly upgrade the dependency of Package A to B to v1.1

All versions of protobuf-net.Grpc depend on protobuf-net in >= 2.4.x but it does not start to be until 3.x compatible with .NET Standard 2.0.

In this case that example that you put of dependency of 1.0 and that the 1.1 is the one of netstandard2.0, how we would solve it with protobuf-net?

If the version that we have in the registry.json file (3.0.0) is superior to the dependency that asks (>= 2.4.x) we read that one directly from registry.json entry (because we know that value it's compatible with .netstandard2.0) or do you mean to iterate over the version history of protobuf-net until we find the first one that targets .netstandard2.0 without using the registry.json entry?

(we statically resolve the dependency >= v1.0 at startup time)

I did not understand this sentence, can you explain it better?

The Package A would then say in its dependencies description that it really depends on v1.1.

By this you mean that we manipulate the upm package metadata (package.json dependencies) and modify the dependency from >= 2.4.x to >= 3.0.0, right?

[xoofx]

By this you mean that we manipulate the upm package metadata (package.json dependencies) and modify the dependency from >= 2.4.x to >= 3.0.0, right?

Yes. (a different way to express it is (we statically resolve the dependency >= v1.0 at startup time))

I am going to represent it with the same case that we have been given of protobuf-net and I am going to put the minimum versions that support .NET Standard 2.0 (the example of the first post):

    "protobuf-net": {
        "listed": true,
        "version": "3.0.0"
    },

Hm, not sure to understand. When I look at NuGet protobuf-net, the version 2.3.6 supports netstandard 2.0, so why do you need to only register a 3.0.0 version?

[bdovaz]

I am working on it and I have come up with a case where a dependency of a package has in turn another unnecessary dependency that causes it to fail (because there is no target to .netstandard2.0):

https://www.nuget.org/packages/protobuf-net/2.3.6#dependencies-body-tab

As you can see, it depends on System.Xml.XmlSerializer 4.3.0 but this dependency is already included in .netstandard2.0.

@xoofx How did you build this listing, i.e. where did you get it from? I need another one for .netstandard2.0:

https://github.com/xoofx/UnityNuGet/blob/master/src/UnityNuGet/DotNetHelper.cs