How to Develop Grasshopper Components for Rhino 8 Using .NET 7?

Hi All,
I’m looking to build Grasshopper components specifically for Rhino 8 and I’d like to use .NET 7. Anyone have experience with this?

Hi @Franklin_Wú,

You might start here:

and

– Dale

4 Likes

Looks great. Thank you!

By the way, do you know if it is feasible to develop grasshopper plugins using C# 10?

While you can use some C# 10 syntactic features in a .NET 4.8 project by adding <LangVersion>10.0</LangVersion> to your csproj, the other features are only supported when compiling for .NET 6 or later because they require runtime support.

We do compile some of our assemblies in Rhino 8 using C# 10, but only to use some of the new syntax features that don’t break binary compatibility.

Do note that the official Microsoft stance is C# 10 is only supported in .NET 6 or later, so if you want to build your plugin for Rhino 7 or Rhino 8 running in .NET Framework then you need to be careful about what you use. I believe the compiler will complain when targeting net48, but I haven’t verified this.

Alternatively, if you make your plugin only for Rhino 8 running in .NET Core runtime (which is default on Windows, and the only choice on Mac), you can compile using C# 11 and .NET 7. I certainly don’t recommend this choice (at this time) if you want broad use of your plugin. Over time this may change.

Hope this gives some insight.

I’m considering this on a new plugin for support reasons: two platforms (Windows and Mac) might be enough without also needing to do support for and regression testing against earlier version(s).

Do a large fraction of active users (say, those who use Rhino at least once a month on average, which I assume you know for Cloud licenses anyway) typically upgrade within a year of major Rhino version updates?

My uninformed assumption is that there’s a very strong correlation between users who quickly pay to upgrade Rhino and users who are willing to pay for a plugin. If true, then might going 8 only (on a new plugin, so no failure to support existing plugin users) not actually be much of a filter on the market for non-free plugins?

Searching through old posts and public announcements, McNeel doesn’t seem to consider numbers secret so much as not compile and organize them often. Since this kind of information is important to attracting plugin authors, I thought I’d ask.

Just to add to the confusion, here is something else to consider. If you want your plug-in to run when users are using Rhino.Inside Revit then the plug-in will need to support .NET Framework. Revit has announced that they plan on upgrading to .NET 6, but haven’t done so yet.

Same question then about Rhino.Inside Revit: how many zeroes are there on the number of active users?

McNeel provides excellent technical help to devs.

In contrast, it seems like simple questions from the business side that are critical to planning like “What’s the size of the potential market for a plugin?” are well-nigh impossible to find answers for.

Some examples of ways information might be assembled with relatively little effort:
How many active Cloud users exist for V7?
How many active Cloud users upgraded within a year from V6 to V7?
How many users are actively trying the V8 beta?

How many app searches were done on food4rhino last month?
Of those, what fraction included the “[some term]” checkbox on the search?
I don’t know if you store keywords searched for, but popularity statistics on those would also be helpful.