Upgrade a .NET Framework 4.8 plugin to .NET Core in Visual Studio?

[ale2x72 (Alessio Erioli)]

Is there a way to actually upgrade a Grasshopper plugin built upon a .NET Framework 4.8 Visual Studio template to use also .NET Core?

So far, I’ve read the following guides and threads:

Moving to .NET Core

Upgrading VS 2022 solution from Rhino 7 to Rhino 8 SDK

My plugin seems to build and run properly now in Rhino 8, but when exiting Rhino 8 while at debug mode I get the following exception: [image] Is there something missed when configuring the Rhino 8 upgrade?

Time to test your plugins with Rhino 8!

Hi Rhino Developers, it’s time to test your plugins with Rhino 8 if you haven’t already! In particular, the move to .NET 7 is an enormous change which might trip up some existing plugins, which means some plugins might need a few tweaks to work. The benefit can be huge, .NET 7 provides much better performance in a lot of scenarios and we’re now using the exact same runtime on both Windows and Mac. We’ve collated some important information that you might need to know regarding Rhino 8 and the …

Moving plugin to Rhino 8

Hey @samlochner, If you want to support Rhino 7 (win and/or mac), you’ll need to release net48 until you sunset that support. Also to keep in mind. Rhino 8 will likely run net48 for its lifetime as Rhino 8 still runs net48, and Rhino.Inside.Revit is quite popular and has to use the same framework. In theory, for now, supporting just net48 is easier (if you don’t want to do Mac). You can of course start multi-targeting now so you’re prepared for the switch to dotnet and or cross-platform. You’…

All of them suggest a new project using the updated template, either as a starting point or as an added launcher for debugging in Rhino 8 (which I’ve done, but that’s not what I want). I’ve not yet seen a way of actually upgrading a .NET Framework 4.8 project to use also .NET Core. I’m talking about a project whose properties in Visual Studio still look like this:

If I click on “Install other frameworks…” I just get redirected to this site, but nothing changes even after installing the SDK libraries. Of course, .NETCore SDK libraries are already installed on my PC (both 7.0 and 8.0).
I’ve tried to use multiple <TargetFrameworks> in the .csproj file as CSykes suggests here: in my .csproj file there is a <TargetFrameworkVersion>v4.8</TargetFrameworkVersion> line, and if I try to replace it with <TargetFrameworks>net4.8;net8.0</TargetFrameworks> I get an error code 0x80004002 in the solution, and the solution itself is not loaded.

So, is there an actual way to upgrade an old 4.8 project to use also .NET Core? Or is starting from a new, updated template the only way? If so, how can I preserve the old plugin GUID so that it is effectively a new version and the new version does not install in parallel with the old one? Or maybe I just missed something along the way?

[ale2x72 (Alessio Erioli)]

@curtisw @CallumSykes tagging you as the authors of the “Moving to .NET Core” page, maybe you can provide some insight on my question (I think my post went under the radar….).

[CallumSykes]

There’s no real difference between a netfx project and a netcore project.

@ale2x72

I’ve tried to use multiple <TargetFrameworks> in the .csproj file as CSykes suggests here: in my .csproj file there is a <TargetFrameworkVersion>v4.8</TargetFrameworkVersion> line, and if I try to replace it with <TargetFrameworks>net4.8;net8.0<TargetFrameworks> I get an error code 0x80004002 in the solution, and the solution itself is not loaded.

After you change it (and all your other .csproj’s) you’ll also need to clear your bin and obj folders, then try a full rebuild. If that still has errors, copy them into this thread and we’ll take another look.

[curtisw (Curtis Wensley)]

Hey @ale2x72,

The usual way to migrate older .NET framework projects is to first convert it to an sdk-style project.

To do this manually, here are many changes that you’d need to do the the .csproj other than just changing <TargetFrameworkVersion> to <TargetFrameworks>, such as removing other properties, imports, changing the header, etc.

You might want to take a look at the .NET Upgrade Assistant, which is the official MS tool to help do this. It usually does a good job, but there may be other minor tweaks you need to do after it has updated your project.

Hope this helps.

[mlukasz87 (Łukasz)]

Just a note, .NET Upgrade Assistant is a legacy package. Latest Visual Studio versions have it built in, but it is hidden under “Legacy” setting in Modernize section of options, because M$ is pushing its new Modernize tools using Copilot requiring Copilot subscription.

[ale2x72 (Alessio Erioli)]

Thanks everyone, these were all very helpful suggestions!

@mlukasz87 Thank you in particular for your note! In my search for solutions, I did find the suggestion to use the .NET Upgrade Assistant, but I hit a snag when I saw Microsoft discontinued it in favor of Copilot (burying it in the Legacy settings…. jeez…).

Long story short, I was able to upgrade the project using the .NET Upgrade Assistant, plus a few post-upgrade adjustments (also comparing the result with a new test solution). In case this might help others, here’s what I had to do:

• the upgrade assistant migrated to .NET Standard 2.0, so I just had to change that using the <TargetFrameworks>net4.8;net8.0</TargetFrameworks> instruction in the project file
• when building the solution, the output plugin file is saved as .dll (not .gha), with an error in post-build events instructions. To fix this, I removed those instructions and added <TargetExt>.gha</TargetExt> to the .csproj file
• I created the two debug launch profiles for Rhino 8 netcore and netfx based on the brand-new test solution

For now, everything seems to work fine, thank you all again!