Discuss .NET 7 #1
Description
We need some kind of FAQ section with topics like this.
Here's what I wrote on the Google group:
The .NET Core series of runtimes (for our purposes .NET 6+) imposes a hard restriction that only one version of the runtime can be loaded in a process.
So an add-in targeting .NET 6 cannot run alongside an add-in targeting .NET 7. (Though .NET 6 and .NET Framework 4.x can work simultaneously.)
If your users use some add-ins targeting .NET 6, no add-in targeting .NET 7 will work. Or if the .NET 7 add-in is loaded first, none of the .NET 6 add-ins can run.
My thinking for Excel-DNA has been to limit support to .NET 6 for now (in addition to .NET Framework 4.x), so that we don't have to deal with this conflict.
Hence, no support for .NET 7 is currently available or planned.
For .NET 8+ there is some improved support for precompiling add-ins to native code (using the .NET NativeAOT feature).
In theory, one could make a .NET 8 add-in that is compiled using NativeAOT, and load this alongside an add-in targeting .NET 6.
However, NativeAOT has various restrictions around which APIs and libraries are supported, and only experimental COM support.
And support for the from the Excel-DNA side would be a substantial undertaking, and so the timing would depend on the support and sponsorship we have.
As things are now, I expect it to take a while to get a prototype going and see how we that would relate to the current toolkit.
My suggestion for now is to look hard for ways to stay on .NET 6 for the foreseeable future.
That might mean other libraries you depend on will have to multi-target for both .NET 6 and .NET 7+.
It's not a great answer, but the .NET developers have decided on this as the versioning strategy, and the single-version-per-process limit by design.
Another approach might be to work on an out-of-process model, where you run a small proxy add-in targeting .NET Framework or .NET 6 in the process, and marshal to an external process that hosts the .NET 7 add-in. I don't think there are any technical problems with implementing this, but it would be some work and getting good performance might be an issue, depending on your UDF usage patterns.