You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: