When can we have a version for .Net Core?

[WestXu]

Now we have a ODBC for .Net Core and a MySQL.Data for .Net Core. UWP is now running on .Net Core.

So when can we have a ExcelDna for .Net Core version, so that we can do many interesting stuff like calling a UWP interface page when using excel, which is impossible for other kinds of addins?

[WestXu]

And it seems Microsoft.Office.Interop.Excel can work on Core too (untested). You only have to add a explicit translation sometimes for some reason, like this:
Worksheet ws = (Worksheet)wb.Sheets[1];

[govert]

Note that you can compile libraries for .NET Standard and use them under the .NET Framework in your Excel-DNA add-in without problems.

There are a few reasons why the .NET Core runtime is not likely to be supported by Excel-DNA any time soon:

• The Excel C API that allows us to integrate with Excel is only supported on the Windows version, so .NET Core support will not let Excel-DNA run on additional platforms. This makes the motivation for using .NET Core in this context unclear.

• .NET Core has very limited support for COM interop, so Excel interaction would be limited to the C API, and all COM-based features like RTD, Ribbon extensions, UI extensions would be very problematic to implement.

• .NET Core does not have support for isolation inside the process (which AppDomains provide in the .NET Framework). So multiple having multiple add-ins based on .NET Core could be a problem.

So it's not something that is on my roadmap at the moment. Perhaps as the runtimes converge over the coming years, there might be a different answer.

Note that Microsoft's official approach to making cross-platform add-ins for Excel is based on the Javascript API.

[WestXu]

Ok I understand. Thanks for your patient explanation. Best regards.

[govert]

I'm not sure everything I said is true...

I think there's a case for investigating this a bit more, so I'll keep this as an open issue.

[govert]

I've done a small experiment with .NET Core and the .NET Native tools (using CoreRT). It's possible to make native .xll add-ins in C# that way, and it worked fine (at least under 64-bit - the state of CoreRT support for 32-bit is not clear, but it's coming). Whether there is any motivation for doing this is not clear, but the resulting add-ins would be pre-compiled to native code, so would load quickly and not be prone to easy decompilation. On the other hand, the COM interop both ways would be tricky.

[WestXu]

The .NET Core 32-bits is available at the official download site, the small link under the big 64-bits download button.
BTW I happened to notice that the popular python package, named xlwings, to create excel add-in with a ribbon ui and UDFs defined by python codes, is available both on pc and mac (including the ribbon). Can ExcelDna achieve this with .NET Core?

[govert]

The 32-bit issue is with CoreRT and the .NET Native part, not .NET Core itself. I'm sure 32-bit support there will come soon.

xlwings takes a different approach to the integration. They don't use the Excel C API, instead they generate VBA code that does the interop between Excel and Python - that's. One could presumably do the same with .NET Core, though it would basically mean starting from scratch with an approach I think is not so good, just to support the Mac. I would suggest for cross-platform support one rather considers the JavaScript direction Microsoft is committed to, rather than relying on VBA.

Another Python integration tool is called PyXll - it takes the same approach as Excel-DNA with a small native .xll (and has the same Windows-only restriction).

[govert]

@WestXu It seems even with xlWings the UDFs are not available on Mac - From the xlWings Docs I read:

UDFs are currently only available on Windows

and from the xlWings home page

On Mac, all UDF related functionality is not available

[WestXu]

Oh that's right, I didn't notice it before. So it's true that there is not much reason to port the project to .Net Core.
I guess all desktop developers are facing this situation, that wpf and winform are abandoned by MSFT, and uwp with .Net Core is not good enough for us to port to.
We'll see where MSFT will lead us at the build conference being held next month.

[govert]

@WestXu Indeed - not clear what overall Windows strategy really is. From the Office and Excel team at least the guidance is clear - JavaScript is the only extension technology they are pushing.

I'd like to do a bit more on the .NET Core and CoreRT side in future - I think there are some reasons to explore this, even in a Windows-only context. It might have an excellent performance and security story, letting C# cover a bit more of the space C++ currently does.

[hell-racer]

I guess all desktop developers are facing this situation, that wpf and winform are abandoned by MSFT, and uwp with .Net Core is not good enough for us to port to.

It seems like they changed their minds. They try to make WPF and WinForms work on .NET Core 3.0:

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

So it maybe it would be nice to be able to write addins with .NET Core 3 + WPF/WinForms (still targeting Windows only though). What do you think?

[govert]

@hell-racer I think it will be possible and a good idea to target .NET Core in future. I've added it to the rough 'roadmap' too (#189) as something I imagine for Excel-DNA version 2.0.

I've done some experiments on doing native compilation with CoreRT and had a look at the .NET Core hosting side too, and I think there are no serious technical constraints, and potentially good performance benefits.

In terms of time frame, I think if .NET Core 3 is released in 2019, then we might see a version of Excel-DNA that supports .NET Core in the early 2020s. If there is interest from commercial support clients or other sponsorship, we could do it sooner of course.

[ekanna]

FYI

Announcing .NET Core 3.0 on Sept 23, 2019
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/

Next release after .NET Core 3.0 will be .NET 5
https://devblogs.microsoft.com/dotnet/introducing-net-5/