I have a question related to Moving to .NET 7 and the plugin package manager. Is it possible to create packages which contain a .NET FrameWork 4.8 as well as a .NET 7 build, such that Rhino can choose whatever is best according to the runtime chosen with SetDotNetRuntime?
Many thanks @curtisw!
A short related follow-up question: Is there a way for a plugin to determine whether Rhino 8 is currently configured to use .NET Framework 4.8 or .NET 7 (SetDotNetRuntime)?
Hi Alex, does this help?
Cheers,
Jon
@jonm many thanks for this hint!
Just as an FYI, this issue was implemented in 8.2
Thanks and fantastic!
@curtisw I have a question about the <BuildYakPackage>True</BuildYakPackage> directive used in this example.
This suggests that there is some functionality that automatically builds yak packages. For our plugin projects, I built custom build targets that create the manifest file and call yak.
@curtisw I ran into an issue related to the new multi-target capabilities described here.
When calling yak build to build a multi-target package, I get this exception:
FATAL: An unexpected error occurred
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
bei Yak.Helpers.Content.GetInspector(String path)
bei Yak.Cli.Commands.BuildCommand.Execute(String[] args)
bei Yak.Cli.Program.Main(String[] args)
The directory I am calling yak from contains this:
The same happens when calling yak spec to create a new manifest.
Version of yak used: Yak 0.13.0 (0.13.8809.28501), Rhino 8.4 (8.4.24044.15001)
Hey @snabela,
Sorry that was not meant to be in the sample. I do have plans to add that type of functionality to our nuget package so you can more easily create yak packages during the build process (RH-78252), but is not done yet. 
Ah darn, I’m seeing this too now, but didn’t initially. It looks like it depends on which .rhp/.gha it finds first, if it finds the net48 version first it works, but it doesn’t if when it finds any of the net7.0 versions first. I’ve written up RH-80648 to get that fixed up asap.
Thanks for reporting the issues!
Got it, I was already suspecting that
Actually I am about to publish a plug-in template on GitHub that also addresses this issue.
Great, many thanks!
Many thanks for your great support!
@curtisw this Grasshopper and Rhino plug-in template supports building multi-targeted packages once the problem in yak has been fixed: GitHub - shapediver/GrasshopperPluginTemplate: Best-practice template for a Grasshopper and Rhino plugin using a shared library and tests
(I might implement a workaround in the meanwhile, should be simple).
Update: When using yak.exe contained in Rhino 8 SR 7 to try and build a multi-targeted package I get this error message:
"C:\Program Files\Rhino 8\System\yak.exe" build
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'DocoptNet, Version=0.0.0.0, Culture=neutral, PublicKey
Token=7a38c71da49a547e'. Das System kann die angegebene Datei nicht finden.
File name: 'DocoptNet, Version=0.0.0.0, Culture=neutral, PublicKeyToken=7a38c71da49a547e'
at Yak.Cli.Program.Main(String[] args)
Actually, this problem happens every time I call yak.exe in SR7.
Update: yak.exe works again in Rhino 8 SR 7 hotfix
@curtisw the problem came back in Rhino 8 SR 8:
FATAL: An unexpected error occurred
Yak.Inspectors.InspectionException: Inspection failed (couldn't load Grasshopper.dll)
at Yak.GrasshopperAssemblyInfo.LoadGhAssemblyInfo(String path)
at Yak.GrasshopperAssemblyInfo.LoadFrom(String path)
at Yak.Inspectors.GrasshopperAssemblyInspector.Inspect()
at Yak.Helpers.Content.ScanDirectories(List`1 directories, Boolean returnAll)+MoveNext()
at Yak.Helpers.Content.GetInspectorsInternal(String path, Boolean returnAll)+MoveNext()
at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Boolean& found)
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
at Yak.Helpers.Content.GetInspector(String path)
at Yak.Cli.Commands.BuildCommand.Execute(String[] args)
at Yak.Cli.Program.Main(String[] args)
Hi @snabela, were you able to fix this problem? or was there a trick which fixed it. I am facing it as well when trying to build a multi-target package based similarly on your template. Using Rhino 8 SR 16.
On my multi-target implementation for Rhino 8 I get this:
And on my non-multi target plugin for Rhino 7 I get a similar message in a different format.
I did try re-building my older version of the plugin and it seemed to work okay, so I dare say it is something with the way the project is compiled.
Try to use Visual Studio to build it rather than do it manually.
The newest VS extension has the option to create .yak packages.
For adding icons, check this:
@xliotx Thanks alot for your response. It has helped up to release the multi-target version.