System.Threading.Channels - request version bump to v8

Rhino Developer
1

Hi there,

Rhino ships with System.Threading.Channels v7
There is now a v8.

v8 is a required dependency of a dependency of a nuget dependency of our plugin
[yes that took some debugging! - i will spare you the details]

For now i’ve simply rolled back the nuget upgrade which requires the update.

However I thought I’d post here & make the request to bump the version to v8 if feasible.

Thanks

3

Hey @david.birch.uk,

We unfortunately cannot only update that single assembly. Have differing versions of dependent assemblies in Rhino as that can cause multiple versions of these strong named assemblies being loaded, causing all sorts of problems at runtime, especially when using Rhino.Inside (but not limited to).

In this case, we include it as a dependency of Microsoft.CodeAnalysis.* and possibly others. We would also have to update all of these to version(s) that depend on that exact version, and all other assemblies that also depend on all of those assemblies, and so on.

I am working on RH-80178, which I hope can start to resolve some of these issues in .NET 7, but in .NET 4.8 you’d still be stuck.

If you can list the package(s) you are trying to use, we can try to figure out a way to get that going either as things are, or determine if we need to update all assemblies that depend on it in Rhino.

Cheers,
Curtis.

1 Like
4

Thank you @curtisw,

Understood, I thought you’d probably have constraints.

The dependency chain that caught me out is as follows:

  1. Revert Serilog.Sinks.Elasticsearch to v9.0.3
  2. Because it depends on Serilog.Sinks.PeriodicBatching v4.0.0
  3. Which depends on System.Threading.Channels v8.0.0
  4. However Rhino already loads v7

For the present we can run with ElasticSearch v9 as it remains compatible.

We are .net 7 only for our current product version. Having our own Assembley Load Context does sound like a promising way forward.