As per the title…
Any clues please?
Thanks
Paul
Make sure you set debugging to .net core. I typically start from a C++ project where you can also select the debugging type to do, like mixed with .net core (meaning .net 7), or mixed with .net framework.
If you do not want to compile your .net plug-in with .net 7 you can give the /netfx
command-line argument, that makes Rhino start with .net framework. But note that Rhino 8 is supposed to work with .net 7, the /netfx
is a stopgap measure for plug-in developers to use until they get their plug-ins compiled with .net 7.
ah you beat me @nathanletwory
Our projects have a several launch profiles.
you can copy them to your project by placing them in <yourproject>\Properties\launchSettings.json
{
"profiles": {
"Rhino 7": {
"commandName": "Executable",
"executablePath": "C:\\Program Files\\Rhino 7\\System\\Rhino.exe"
},
"Rhino 8 - .net 4.8": {
"commandName": "Executable",
"executablePath": "C:\\Program Files\\Rhino 8\\System\\Rhino.exe",
"commandLineArgs": "/netfx /nosplash"
},
"Rhino 8 - .net 7": {
"commandName": "Executable",
"executablePath": "C:\\Program Files\\Rhino 8\\System\\Rhino.exe",
"commandLineArgs": "/netcore /nosplash"
},
"Rhion 8 - net 8": {
"commandName": "Executable",
"executablePath": "C:\\Program Files\\Rhino 8\\System\\Rhino.exe",
"commandLineArgs": "/netcore-8 /nosplash"
}
}
}
updated with net 8 for Rhino 8
Awesome - thank you @nathanletwory and @david.birch.uk .
Paul
sorry to necrodive this post , but,
when i use the /netcore slash from here it fires up in netfx anyway.
has the nomenclature changed since netcore8 was introduced?
Hi Chris,
I’ve just tried this and I’m not able to replicate.
I find that the /netcore flag overrides the choice of the SetDotNetRuntime
command.
I’ve updated my post above to include the new .net 8 flag
Thanks.
The issue was not my plugin it was another plugin Artisan, but no clear error error messages from VS that it failed or why it was loading the wrong one, after a lot of scratching and tweaking it turns out the other plugin has a SuppressIldasmAttribute flag set, so VS faults (without an error in my case) and loads the next available debug option.
(in my case /netfx, and perhaps this is default Rhino behaviour, if one version fails load the other?),
anyhow, since that other plugin is netcore only it fails to load in netfx and Rhino keeps happily booting into to the wrong architecture…
I set the offending plugin not to load and all working with /netcore again.
I will report this funky behaviours to VS devs as well we should have an option to ignore SuppressIldasmAttribute flag, as we are not debugging THAT code…