Some plugins won’t work any more in Rhino 8 unless the runtime is reverted to .NET Framework. The Grasshopper-Tekla integration is one of these (since if using .NET 7 it’s unable to communicate with the Tekla Structures process over the Tekla API which is built on .NET Framework).
The problem is of course that with .NET Framework as the runtime, other plugin releases targeting only .NET 7 won’t work. This is starting to really hurt some users that now can’t use certain plugins together but need to switch runtime in between.
Is there a way to resolve this, i.e. basically run plugins requiring different runtimes simultaneously in Rhino (probably doesn’t even make sense technically)? Or any other advice or best practices?
Related to this:
Just recently, Lunchbox and Karamba3D started supporting both runtimes via their Yak packages, in the similar fashion as discussed here:
Now using both of these great plugins is a delight and sharing scripts is working again. I think this is at least a decent workaround until all plugins can move to .NET Core.
Which plugins are the main ones causing problems running in .NET Framework?
I think it is very important to understand that any software has a limited and unknown lifespan. Any simple script you write, even a simple GH definition, has this problem. So any developer, including your worst Grasshopper user in your team, needs to be aware of this. It essentially needs to count in, whenever you decide for or against an external dependency.
Now if you upgrade your dependencies and/or Rhino, you have to assume that things don’t work anymore. This needs be always considered before upgrading. So if things magically break due to API changes or different underlying frameworks, then your tooling is simply not migrated. If migration is not possible due to missing upgrades of external dependencies, then this is predominantly your problem! If your developers didn‘t care, you need raise awareness to them.
So given that its too late now, what are your options? Either you roll back to Rhino7 with old plugin versions or you replace all inactive dependencies. Anything else will only worsen the problems on a longer run. Imagine the person who does the Tekla plugin, suddenly disappears. Then you wait forever. To sum it up, if doable, reduce dependencies as much as feasible while developing features/definitions
Thanks that’s a possible solution, if we could just somehow force all plugin devs to use the approach
This issue has been raised by a couple of big GH/Tekla users lately. I’m not aware of exactly which plugins are .NET 7 exclusive, but there are certainly more than one, and this will probably happen more and more over time with new releases.
Agreed on trying to keep the external plugins to a minimum! Then again there are always some tools that are essential for a given workflow - if you want to push things to Tekla you simply must have external code that uses the .NET Framework, and probably similar reasons exist for using some of the .NET 7 tools.
Long term Tekla will likely move over to .NET core as well but for now we’re kind of stuck in the Framework world. Hence why I’m hoping there’s a solution to make tools running on either platform work nicely together.
Sounds like you are developing the plugin?! Have you considered a middleware architecture? What if you only run small interfacing application in RH/GH, which communicates over IPC (LocalTCP/Shared Memory/ Pipes etc) with Tekla or with an NET-Framework based client? Then you would not need to use Framework technology within Rhino! It also reduces problems in case of hard crashes.
Thx, a fair suggestion. So I did a bit of PoC:ing yesterday with named pipes. For text it works well, but it would of course require a lot of changes in the implementation.
In the framework runtime we’re able to pass around .NET instances of the actual Tekla objects between components in GH. This removes a layer of wrapper classes, and also makes it easy for users to script their own operations around the model objects in case the integration doesn’t offer something out of the box.
Thinking of it I guess any user component that interacts with Tekla in .NET 7 would need to use pipes or similar workarounds, which makes life a fair bit harder for occasional scripters.
There’s probably a lot more (like performance) to consider before undertaking a rewrite and I have a feeling it would require a massive overhaul. I don’t think this would happen anytime soon even if it was the only option
I don’t know if you’ve used Speckle, but you might be able to send the information you need via Speckle between Tekla / Rhino and not need to rely on the LiveLink.
Write your own plugin
Tekla is a peculiar app. I don’t know if you’ve ever tried this, but you can boot up an ironpython CLI and script changes inside a running Tekla App instance from the CLI, which is unlike any app I’ve coded with before.
All this to say, I think there’s likely a way to create a plugin to make this work. net48 can be referenced from dotnet core. Rhinocommon is only published as net48 for example.
(I understand this is likely too complex, but just incase someone else is curious)
Thanks Callum for your input. As I’ve understood it the main challenge is that the remoting technology the API uses to communicate with the Tekla core process simply isn’t available under .NET core runtime, even if you successfully reference all the .net framework libraries of the API. But I’m fuzzy on the details.
