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/

[govert]

Two of the issues that affect using .NET Core / .NET 5 for Excel-DNA are these - please upvote and comment to get these addressed for .NET 5:

• The worst shortcoming in .NET Core at the moment is the lack of COM support in the dynamic binder: https://github.com/dotnet/coreclr/issues/24246
• .NET Core also does not support multiple instances of the runtime to be loaded into a process: https://github.com/dotnet/coreclr/issues/22529

Otherwise supporting .NET 5 should be technically possible, though it will take some work since the AppDomain and type loading infrastructure will have to be redone. The architecture might however need to change so that there is a single "host" add-in that loads all the .NET Core add-ins into the session, similar to how PyXLL and Jinx works.

@ekanna I presume you see benefits in targeting .NET Core / .NET 5 for your add-in, rather than staying on .NET Framework, even though the add-in will still only work on Windows. If the .NET 5 support were available only as a commercial library at US$ 10 per user per year, would you subscribe to that option?

[ekanna]

@govert

If the .NET 5 support were available only as a commercial library at US$ 10 per user per year, would you subscribe to that option?

No problem at all. What you are asking is a very small and reasonable price. I don't think anybody will have a problem with that.

Thanks for your great work!

[y2kbugger]

Is that per developer or per end user?

…

On Fri, Oct 18, 2019, 05:49 koti ***@***.***> wrote: @govert <https://github.com/govert> If the .NET 5 support were available only as a commercial library at US$ 10 per user per year, would you subscribe to that option? No problem at all. What you are asking is a very small and reasonable price. I don't think anybody will have a problem with that. Thanks for your great work! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#175?email_source=notifications&email_token=ABORVLO7O6ZMLD2TF32ZGK3QPGIEZA5CNFSM4EZ6XGPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBT33BI#issuecomment-543669637>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABORVLPRCOORT3XLDRNEOKTQPGIEZANCNFSM4EZ6XGPA> .

[govert]

@y2kbugger My thoughts would be to have a low per-user subscription to Excel-DNA for the .NET 5 runtime engine. That would help fund future work to improve Excel-DNA.

[jzabroski]

We currently pay AddInExpress $174.50 to upgrade our legacy subscription for one developer (and one user). It's a really important user.

While I can't say I'm committed to supporting excel addins, it might be nicer to have an alternative to AddInExpress that's open source, especially if it will support .net framework.

I looked at the Excel-JS API and it's simply slow. Charles Williams of ExcelFast wordpress has some Typescript benchmarks demonstrating the Javascript is significantly slower than VBA.

Moreover, while Microsoft employees behind Excel-JS have been enthusiastic about answering Stackoverflow questions, I think there is no debate people find it harder to use than VBA. The concept of a context sync and run to completion semantics for add-in code is nice and has desirable goals like ensuring DisplayAlerts = true on exceptions by effectively hiding exceptions altogether with Promises. Still, if you look around, there just isn't a ton of interest in supporting Excel-JS from developers because it can't come close to either managed c# or c++ com.

[jzabroski]

Ideal solution would be for Excel to use ZeroMQ for RTD, btw. Think about it. We have Microsoft Bond for serialization. Just create RTDQ function replacement. If Microsoft did this I think cross platform dev support would be easy.

Here's how I know this solution works.

The general problem with COM, and I think Excel DNA suffers this, is how you can't predict, even if you declare your COM addin to be in a single threaded apartment, that the calling app will behave correctly if it's in a multi-threaded apartment. This is why, Govert, you sometimes see exceptions in your ExcelSynchornizationContext. The only solution is to use DCOM, as it converts threading issues into marshaling issues, which are much easier to debug.

Just my 2 cents. I hate Excel and I tell that to the wealthy investors all the time building investment models in Excel.

Of course, this only solves RTD servers. But that's fine.

ExcelDNA would evolve its RtdServer code away from being a server to just being a Gateway.

[augustoproiete]

@jzabroski:

I looked at the Excel-JS API and it's simply slow. Charles Williams of ExcelFast wordpress has some Typescript benchmarks demonstrating the Javascript is significantly slower than VBA

Links to the articles (I think) @jzabroski mentioned, which are an interesting read:

• Excel JavaScript API Part 1: Overview & Comparison
• Excel JavaScript API Part 2: Benchmark of Read/Write Range Performance
• Excel JavaScript API Part 3: Benchmark of Processing Arrays Performance – Loop vs Reduce vs COUNTIFS vs VBA
• Excel JavaScript API Part 4: The shallow copy problem
• Excel JavaScript API Part 5: The large numbers bug

[jzabroski]

FYI, Visual Studio 2019 removed "Register for COM Interop" from the Project Properties window altogether. Nota bene.

[jzabroski]

@augustoproiete While you're replying to my brain dump... any chance you've successfully used the new Visual Studio 2019 + SDK csproj file format to debug COM add-ins?

I just upgraded to the SDK csproj file format to take advantage of the Nuget package reference simplicity, and it seems that broke the Start external program: "C:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE" experience.

[augustoproiete]

@jzabroski #278 (comment) || https://stackoverflow.com/a/58864762/211672

[jzabroski]

@augustoproiete To be clear with my comment above, I am not using ExcelDNA, but my approach is so similar to yours, that I thought to ask and compare notes for the betterment of both of us. (I am actually hoping to use ExcelDNA in the future, but for now, my first goal is to upgrade legacy code written in pure COM fashion that locates COM interfaces via CLSID's.)

[jzabroski]

Related, I discovered .NET Core has removed all support for "corrupted state exceptions", so if your Excel-DNA project tries to use .NET Core dll's, expect that you will not be able to recover or respond to "corrupted state exceptions". See:

https://github.com/dotnet/coreclr/issues/9045
dotnet/coreclr#10957

[MPRavn]

If the .NET 5 support were available only as a commercial library at US$ 10 per user per year, would you subscribe to that option?

@govert I know this is an old issue, but if you get around to updating for .NET 5 I would in all likelihood be interested in ~5 licenses.

[y2kbugger]

I'd be in for 25+ licenses as long as it stays open source.

[y2kbugger]

@govert It looks like the dynamic COM (roadblock #1) has been resolved here: dotnet/runtime#33060

[govert]

.NET 6 is now supported in Excel-DNA 1.6 - see https://groups.google.com/g/exceldna/c/YhBhXi5NQFE