If I may add a comment here. We wanted to use a whole load of complex code written over many years in .Net Framework, but have a .Net Core front end that would allow for future proofing the look and feel of the product and maybe now we could even update it to use Maui, but we won't have yet updated (had time to update) the .Net Framework 4.8 code.
I don't know if anyone might find it useful, but what we have done is this:
- Create .Net Core projects (front end .Net Core WinForms in our case) and associated DLL projects containing most of the functionality (allowing us to change WinForms for Maui for instance)
- Create a new .Net Framework project (a simple EXE with a hidden interface running in the background at the same time as your main .Net Core interface), containing references to old .Net Framework DLLs that would take too long at this point in time to update and test.
- Create a .Net Standard DLL that both projects can reference, this being a communication DLL to allow simple messages (ints/strings etc.) to be sent over Pipes (enum defined here too for the message type, and consider using threads for no blocking).
Voila! You can now use your old Framework DLLs via the quick Pipe messaging DLL. You just set up the code once to handle the communication so that you can do a standard call, and the data is returned to a standard place. Use of Delegated Callbacks are handy to get data back to the higher level interface places.
Like I say, this is not for everyone, but once it's set up it just works. It's all standard tested technology. We just simply don't have the time at the moment to update and test this quite complex .Net Framework code. This was relatively quick to set up.