Excel-DNA / Excel-DNA/Excel-DNA.github.io

Discuss .NET 7

オープン
#1 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
JavaScript
スター
0
フォーク
4
PR マージ指標
30日以内にマージされた PR はありません

説明

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.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

まず issue 本文とリポジトリに既存の FAQ またはドキュメントの構成を確認し、このトピックをどこに置くべきか判断します。.NET 6/.NET 7 の互換性の状況と、issue に記載された代替案を文書化し、FAQ 内での配置と範囲について合意できれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
csharp
領域
documentation
issue の種類
ドキュメント
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
30/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。