Dependencies similar to Binding redirects

[bdovaz]

Conversation derived form https://github.com/protobuf-net/protobuf-net.Grpc/pull/263

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

{
    "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",
        "dependencyOverrides": {
            "protobuf-net": "3.0.0"
        }
    }
}

Override 2.4.0 dependency from the following link with 3.0.0: https://www.nuget.org/packages/protobuf-net.Grpc/1.0.0#dependencies-body-tab

So the idea is that in all versions from 1.0.0.0 onwards of protobuf-net.Grpc if the protobuf-net dependency is found in a version lower than the one defined in the "dependencyOverrides" section it overwrites it with the one defined in that section so that it works like the binding redirects, no?

Adding this functionality opens doors to add packages that had invalid dependencies and we could not add until now.

Sometimes I have the feeling that I spend a lot of time contributing to this project through PRs but the reality is that for developers like me who work in companies with products and are tied to LTS versions of Unity, CoreCLR, Unity SDK style csprojs, etc. are a long way off. We are talking about if hopefully it gets in 2024.x until 2025 it would not be in the LTS.

UnityNuGet is a huge salvation for those of us who are doing complex developments that require multiple NuGet packages and by the nature of being products require to be updated periodically and it doesn't work with updating hundreds of dlls by hand dragged into /Assets.

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.

[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]

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]

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.

[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

[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