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

Discuss .NET 7

Đang mở
#1 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Ngôn ngữ chính
JavaScript
Star
0
Fork
4
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

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.

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu bằng cách xem xét nội dung issue và cấu trúc FAQ hoặc tài liệu hiện có của repository để xác định chủ đề này nên được đặt ở đâu. Công việc được xem là hoàn thành khi tình trạng tương thích của .NET 6/.NET 7 và các phương án thay thế được mô tả trong issue đã được ghi lại, đồng thời vị trí và phạm vi trong FAQ đã được thống nhất.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
csharp
Lĩnh vực
documentation
Loại issue
Tài liệu
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
30/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.