RhinoCommon nuget package frameworks

[snabela (Alexander Schiftner)]

The RhinoCommon and Grasshopper nuget packages only support frameworks net48 and net481. Is there a plan to add support for net7.0? Asking because of the build warnings this causes when building plugins on Mac for Rhino 8.

[david.birch.uk]

see Add .NET 7 target to nuget package(s) : RH-77311 (myjetbrains.com)

Rhino.Inside .NET Core 7.0

We do not have a nuget package for RhinoInside and Rhino 8 available yet. That said RhinoInside is really a single C# file and can be directly included in your project. We have done this and made some slight modifications in order to get things working with Rhino 8 and .NET 7 in this project which is part of Rhino.Compute for Rhino 8

Rhino WIP Feature: Get ready for .NET 7!

Are .NET6 compatible nuget packages available?

I think the answer remains “soon”

[Goswin]

here too: RhinoCommon .net6 &.net7? - #10 by Goswin

[snabela (Alexander Schiftner)]

@curtisw can you provide a rough timeline for this?

[snabela (Alexander Schiftner)]

One more thing to add here: It would be great if you could include RhinoCodePlatform.GH.dll and RhinoCodePlatform.GH.Context.dll in one of the nuget packages as well. At ShapeDiver we need to reference these DLLs for precompiling scripts. @eirannejad knows more about this

[Goswin]

@snabela why not provide those as separate nuget packages?

[snabela (Alexander Schiftner)]

@Goswin separate nuget packages would be completely fine! The important part is to get them via any nuget package, instead of having to reference them locally

[CallumSykes]

You may notice the ticket @david.birch.uk linked has been reviewed.

The latest release of Rhino 9 WIP Nugets are net48 and net8.0.

RhinoCommon 9.0.25091.12305-wip

@snabela

@curtisw can you provide a rough timeline for this?

.net7.0 for the Rhino 8 nugets should release with 8.19

[Goswin]

@CallumSykesThankks, It works in RH 9 WIP. I can now build and load net7 nuget packages

[CallumSykes]

The latest release of Rhino 8 Nugets are net48 and net7.0 and now available.

RhinoCommon 8.19.25098.10001-rc

[Goswin]

I tried it, but it needs to run on SR19, that is not released yet. I’ll wait for that.
@curtisw Would it be possible to also build a net7 nuget for older service releases too, so that the latest version is not required?

[wim (Wim Dekeyser)]

Hi -

@Goswin

but it needs to run on SR19, that is not released yet.

Possibly not what you are saying, so FWIW, the first public SR 19 SRC was released 18 hours ago.
-wim

[curtisw (Curtis Wensley)]

@Goswin

Would it be possible to also build a net7 nuget for older service releases too, so that the latest version is not required?

Sorry, this is unfortunately not feasible. The changes needed to our codebase was not all that trivial to be able to support building the net7.0 assemblies needed for the NuGet package. Porting those changes to older versions of Rhino would potentially break things without proper testing, which is why it is only in the SRC.

[visose (Vicente Soler)]

@curtisw I have a custom Nuget package expected to be referenced by Grasshopper plugin projects. Those projects get the Grasshopper and Rhinocommon packages as transitive dependencies from this custom package.

This was working fine, but uprgrading to 8.19 causes an issue because the Grasshopper 8.19 package uses <frameworkReference name="Microsoft.WindowsDesktop.App.WindowsForms" /> to get the Windows Forms reference at compile time and the Rhinocommon package has some MSBuild targets to silence the eventual error when not targeting net7-windows.

But for this to work, RhinoCommon cannot be a transitive package, it must be referenced in the top project.

One possible solution might be if you could copy RhinoCommon.targets to /buildTransitive instead of /build when creating the nuget package. Would this be possible in a future version?

What I’m currently doing to solve this is to use GeneratePathProperty="true" to get the .props and .targets files from the RhinoCommon package and including them in my custom package.

Btw, what is the advantage of using frameworkreference instead of the previous:
<PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies.net48" Version="1.0.3" ExcludeAssets="all" GeneratePathProperty="true" /> <Reference Include="$(PkgMicrosoft_NETFramework_ReferenceAssemblies_net48)\build\.NETFramework\v4.8\System.Windows.Forms.dll" Private="False" />

I also had to add the property <EnableWindowsTargeting>true</EnableWindowsTargeting> to get it to compile in Linux.

[curtisw (Curtis Wensley)]

Hey @visose,

@visose

This was working fine, but uprgrading to 8.19 causes an issue because the Grasshopper 8.19 package uses <frameworkReference name="Microsoft.WindowsDesktop.App.WindowsForms" /> to get the Windows Forms reference at compile time and the Rhinocommon package has some MSBuild targets to silence the eventual error when not targeting net7-windows.

Thanks for raising the issue regarding the .targets file not being transitive, and proposing a solution. I’ve logged that as RH-87473 Some RhinoCommon targets should be in buildTransitive in nuget packages.

@visose

Btw, what is the advantage of using frameworkreference instead of the previous:
`<PackageReference Include=“Microsoft.NETFramework.ReferenceAssemblies.net48” …

Using this strategy has a few drawbacks:

1. You can not add <PackageReference>'s like this in a nuget .targets file, so you would have to do this directly in the .csproj
2. You could inadvertently use APIs that are actually no longer available in .NET Core, causing runtime loading errors, like MenuItem and ContextMenu
3. Referincing the Microsoft.WindowsDesktop.App.WindowsForms framework also allows you to use newer APIs not available in net48.
4. You will get a build warning with the above that you are referencing a net48 assembly from .NET Core

Cheers!
Curtis.

[visose (Vicente Soler)]

Thanks.
I had <PackageReference.. in a .props file (rather than .targets) inside the package, and I think that worked (consuming projects had compile time access to the Windows Forms dll without having to add it to their .csproj).

How do points 2 and 3 apply to cross-platform development? Can you still run into non existent APIs in Mac? Are the new APIs also available in Mac?
I presume it’s still best to use as little as possible of System.* to get it working with Grasshopper and use Eto.* whenever possible.

[curtisw (Curtis Wensley)]

@visose

I had <PackageReference.. in a .props file (rather than .targets) inside the package, and I think that worked (consuming projects had compile time access to the Windows Forms dll without having to add it to their .csproj).

It only works after the first restore from my testing (you need to restore packages twice to get it), and causes all sorts of build problems. I’ve tried it (with other projects) and it is a non-starter unfortunately.

@visose

How do points 2 and 3 apply to cross-platform development? Can you still run into non existent APIs in Mac? Are the new APIs also available in Mac?

Yes, all these APIs are available on Mac. Grasshopper itself is written in Windows Forms and System.Drawing. We have our own implementation of both of these for Mac that lights them up. Only some of the popup dialogs are written in Eto, but many of the controls on those are still written in WinForms.

@visose

I presume it’s still best to use as little as possible of System.* to get it working with Grasshopper and use Eto.* whenever possible.

Yes, I would agree with this. However, to write custom Grasshopper components you will still need to use System.Drawing (for the canvas), and WinForms (for customizing context menus and other stuff).

Hope this clears it up a little.