Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss .NET 7 #1

Open
govert opened this issue Mar 2, 2023 · 0 comments
Open

Discuss .NET 7 #1

govert opened this issue Mar 2, 2023 · 0 comments

Comments

@govert
Copy link
Member

govert commented Mar 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant