Rhino.Inside NuGet Package pulling old RhinoCommon

Rhino.Inside
, , ,
1

@stevebaer per your suggestion I’ve removed all NuGet packages for RhinoCommon and RhinoWindows while using Rhino.Inside. However unless I keep either the RhinoCommon or Grasshopper package our code fails to compile.

image
image1192×266 24.3 KB

We rely on Mesh.MergeAllCoplanarFaces function. I think it was added in RhinoCommon v7 SR9.

But it looks like the RhinoInside pulls a much older RhinoCommon, do you have any workarounds to tell Rhino.Inside to pull the newest RhinoCommon?

image

@kike /@stevebaer thanks for any help you can be.

– J

2

@will can you help me publish an update to Rhino.Inside to nuget that references newer assembly versions?

1 Like
3

You’re welcome to continue using the setup that you were using in the past until we have the nuget package updated. It just seems a bit cleaner to use the nuget package.

1 Like
4

It looks like NuGet defaults to using the “lowest applicable version” to resolve the dependencies. I’ll see if we can get NuGet to instead use the latest compatible dependency versions when installing the Rhino.Inside package.

For now, explicitly installing the versions of the RhinoCommon/Grasshopper packages is the right approach. I think the warning above can be resolved by also explicitly installing the matching version of the RhinoWindows package.

5

Couldn’t we create a Rhino.Inside 7.1 that had lowest applicable version of RhinoCommon of 7.1?

6

…and publish a new Rhino.Inside NuGet package for each stable release of Rhino, like we do for RhinoCommon, etc.? This may be the most straightforward approach actually…

The “lowest applicable version” dependency resolution seems to be part of Microsoft’s efforts to make all builds deterministic. We might be able to create a NuGet package that uses “floating” versions (i.e. “7.*”) to grab the latest versions of transitive dependencies during restore, but this leads into conversations about lock files… Maybe best avoided!

7

That’s what I was thinking we could try

1 Like
8

Sounds great, that is what we do for our main app and related Nuget packages.

Thanks for the help guys.

9

@will / @stevebaer

Has this effort moved forward? The latest rhino.inside project in nuget right now is 7.0.0 which has rhinocommon version 7.0.20314.3000 and the latest rhinocommon version in my rhino folder seems to be. 7.26.23009.7001.

10

There haven’t been any required changes since Rhino 7 SR0. If you want to reference a newer version of the RhinoCommon nuget package, then you should be able to.

1 Like