[CrimsonCape]

> But using C# required us to contemplate whether and which dotnet runtime our client supported. Or did we need to ship our own? Isn't this just a small launcher stub? This was just too much complexity outside of our wheelhouse to put between our product and the user. This is not to say that the C# approach isn't valid. It is just that our limited understanding of that ecosystem and its requirements counseled against shipping it as a primary entry point into our application.

You should be able to compile a relatively small, trimmed, standalone, AOT compiled library that uses native interop. (Correct me if i'm wrong, dotnet users). Then there would be no dependency on the framework.

[sedatk]

Or you could target .NET Framework 4.8 which is supported by all Windows OSes out of the box albeit quite outdated.

[Kwpolska]

Their add-in seems quite simple, I imagine there would be no meaningful difference between using the classic .NET Framework 4.8 and .NET 10.

[pjc50]

> You should be able to compile a relatively small, trimmed, standalone, AOT compiled library

Yes-ish. We do AOT at work on a fairly large app and keep tripping over corners. Admittedly we don't use COM. I believe if you know the objects you are using upfront then code generation will take care of this for you. The other options are:

- self-contained: this just means "compiler puts a copy of the runtime alongside your executable". Works fine, at the cost of tens of megabytes

- self-contained single file: the above, but the runtime is zipped into the executable. May unpack into a temporary directory behind the scenes. Slightly easier to handle, minor startup time cost.

[pjmlp]

Yes, provided you are using modern COM bindings introduced in .NET Core, alongside code generators.

[merb]

You can only use .net 4.8 when you create an outlook add-in.

I mean yes you can build it with native interop and aot. But then you would loose the .net benefits as well.