Self contained mode

[aeb-dev]

Hello,

I am trying to create a self contained xll pack so that users dont need to update dotnet runtime everytime dotnet is upgraded. I have playing with addin and csproj option with no luck.

I saw this issue, but my error is different I am getting an exception in the runtime

System.MissingMethodException: Method 'ExcelDna.Loader.XlAddIn.Initialize' not found. at System.RuntimeType.InvokeMember

So my question is, is it possible to create a self-contained xll pack, if so how?

[govert]

No, the add-in can't work in self-contained mode.
This is a limitation of the .NET core runtime when loading into a running process like Excel.

[govert]

Why do your users need to "update dotnet runtime everytime dotnet is upgraded", and how would a self-contained distribution help with that?

We are working on supporting the NativeAOT compilation mode, but whether that can work for you would depend on what other dependencies you rely on.

[aeb-dev]

Why do your users need to "update dotnet runtime everytime dotnet is upgraded"

We have shared packages with the excel-addin project. When a new dotnet version releasedm we upgrade our solution to use the new version. When you compile something with .net10 sdk you can not run it with .net 9 runtime.

how would a self-contained distribution help with that?

When you compile with self-contained flag, the runtime is also published to the output folder

[govert]

So, you make a new version of the add-in that targets .Net 10, but you don't want to install .NET 10 on the client, you rather want to just copy the .NET 10 files into the directory of the add-in?

How do you currently distribute the add-in, just copy a .zip file or similar?

Perhaps you could make an .msi installer that also installs the .NET 10 runtime when you update the add-in.

[aeb-dev]

So, you make a new version of the add-in that targets .Net 10, but you don't want to install .NET 10 on the client, you rather want to just copy the .NET 10 files into the directory of the add-in?

Yes, it is hard in corporate env to install something which requires elevated access. If I can deploy with self-contained I dont need to worry about permission, policies etc. We deploy some of our apps like this, it is very convenient for us

How do you currently distribute the add-in, just copy a .zip file or similar?

We havent decided yet. I saw the example in docs for auto-update. We were trying to test that approach but without self-contained mode I am not sure if it is a good candidate

Perhaps you could make an .msi installer that also installs the .NET 10 runtime when you update the add-in.

If there is no any other hacky way that you can think off for self-contained mode, I think we have to do something similar to this, thanks for the recommendation

[govert]

You can install .NET per-user, without requiring elevation, in any directory you want.
See here: https://learn.microsoft.com/en-us/dotnet/core/install/windows#install-with-powershell
And here: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

Installing .NET through the dotnet-install PowerShell script is recommended for continuous integration and nonadmin installs.

Basically, you install using the dotnet-install powershell script.
Remember you want the "windowsdesktop" version of the runtime for Excel-DNA.

I have not tried this type of installation with Excel-DNA myself, but I believe it should work.

For an installer for your add-in, you can look at the WiXInstaller template project as a starting point:
https://github.com/Excel-DNA/WiXInstaller
You might be able to extend this to also install the runtime, and I suspect you should be able to run that installation with both the add-in and the runtime without elevation too.

[aeb-dev]

I will try and report back. Thanks for the information. I am curios tho, do you know the difference between installing to specific folder and self-contained mode?