Spike: validate self-contained + packed XLL produces a working artifact

[jimmytacks]

Part of #189. Implements the spike called out in spec 0006 under Open Questions.

Goal

Confirm that dotnet publish with <SelfContained>true</SelfContained> + <PublishSingleFile>true</PublishSingleFile> + <RuntimeIdentifier>win-x64</RuntimeIdentifier>, combined with ExcelDNA's Pack="true" mechanism via PublishExcelDnaAddIn, produces a single XLL that loads in Excel on a clean Win11 + Office 365 VM with no .NET 6 Desktop Runtime installed.

Approach

Time-boxed to ~1-2 days.

1. Branch off main.
2. Add a Tournament MSBuild configuration (or a one-off dotnet publish invocation) with the self-contained / single-file settings.
3. Switch the .dna (or a copy of it) to Pack="true".
4. Build, sign, copy to the verification VM.
5. Load via Excel Add-Ins dialog. Confirm Lambda Boss popup opens, a simple LAMBDA call evaluates.

Output

One of:

• ✅ A working hello-world XLL on the VM. Briefly document the working incantation in the issue, unblock issues #BUILD, #README, #INTEGRATE, #VERIFY (links to be added when those issues are created).
• ❌ A blocker (e.g. ExcelDNA self-contained mode broken, type identity issues, runtime probing failures). Document findings, add blocked: tim label, propose spec revision before further work proceeds.

Out of scope

• The full build-tournament-bundle.ps1 script (separate issue).
• README / docs (separate issue).
• Release pipeline integration (separate issue).

[jimmytacks]

Spike result: ❌ Blocker

The spec's proposed approach — <SelfContained>true</SelfContained> + <PublishSingleFile>true</PublishSingleFile> + <RuntimeIdentifier>win-x64</RuntimeIdentifier> combined with ExcelDNA's Pack="true" — is not implementable. Both empirical attempt and primary-source documentation rule it out.

Empirical findings

Branch issue-190-spike-self-contained-xll, ExcelDNA.AddIn 1.9.0, .NET 6 (runtime 6.0.36 present locally).

Attempt 1 — full proposed combo:

dotnet publish addin/lambda-boss/lambda-boss.csproj -c Release `
  -r win-x64 --self-contained true -p:PublishSingleFile=true `
  -o bin\Tournament

Fails with:

error NETSDK1099: Publishing to a single-file is only supported for executable applications.

PublishSingleFile requires OutputType=Exe. Lambda Boss is a class library — the XLL itself is a native loader copied from ExcelDNA's NuGet tools folder with managed assemblies appended as Win32 resources. There is no managed entry point for the apphost-bundle mechanism to wrap. This is a hard .NET SDK constraint, not configurable.

Attempt 2 — drop PublishSingleFile, keep self-contained:

dotnet publish addin/lambda-boss/lambda-boss.csproj -c Release `
  -r win-x64 --self-contained true -o bin\Tournament

Succeeds, but:

• Produces 287 files totalling 156 MB in the output folder.
• No .xll file is produced. ExcelDNA's PublishExcelDnaAddIn / PackExcelAddIn targets do not integrate with dotnet publish in self-contained mode — the publish output is plain managed DLLs + native runtime, with no native XLL bootstrapper.
• Even if we wired up PackExcelAddIn manually against this output, the resulting XLL would still rely on ExcelDNA's loader, which cannot use a side-by-side runtime (see below).

Primary-source confirmation

ExcelDNA author Govert van Drimmelen on Discussion #607:

We don't support the bring-your-own-runtime option of .NET Core, because the add-in isolation mechanism we use (the AssemblyLoadContext etc.) doesn't support that. … only one version of a .NET Core runtime can be loaded into the Excel process.

Official ExcelDNA .NET runtime support docs:

If your add-in will be distributed outside your organization, or on machines that you don't have much control over, then I would suggest targeting .NET Framework.

The ExcelDNA 1.9.0 release notes introduce extended registration, async, object handles, and native-dependency packing — but no self-contained or single-file publish support.

Why ExcelDNA architecturally precludes this

XLL files are native DLLs loaded by Excel via the XLL Manager. ExcelDNA's loader (ExcelDna64.xll) is a small native bootstrapper that locates an installed .NET runtime via the standard hostfxr resolution path, then hosts CoreCLR in-process. The .NET 6 single-file bundler is built around apphost.exe and a managed entry-point — neither concept maps onto a native XLL. The AssemblyLoadContext-based isolation ExcelDNA uses to keep multiple add-ins from conflicting also depends on a single shared runtime in the process.

Recommendation: revisit spec 0006

The tournament use case is real, but the technical path in the current spec is not available. Possible directions, all currently marked Out of Scope on spec 0006:

1. .NET Framework 4.8 port of Lambda Boss. ExcelDNA's officially-recommended path for the "no runtime assumed" scenario. The packed XLL (managed deps embedded as resources via ExcelDnaPack) is a true single-file artifact under .NET Framework, because the .NET Framework runtime is part of Windows. This is the most likely viable path. Would need its own spec — non-trivial migration (WPF 4.x, package compatibility check on Taglo.Excel.Common, YamlDotNet, gong-wpf-dragdrop, Ookii.Dialogs.Wpf).
2. Side-by-side runtime folder. Ship XLL + runtimes/ folder. Loses the single-file UX. Also likely runs into the same isolation issue if another add-in is loaded first with a different runtime.
3. Custom native bootstrap that extracts a private runtime to %TEMP% on load and points hostfxr at it. Substantial engineering, and we'd still be fighting ExcelDNA's single-runtime constraint.
4. NativeAOT. Mentioned in ExcelDNA docs as a future possibility; not available today and would be a larger migration than Lambda Boss — ExcelDNA add-in for LAMBDA library management #1.

Setting blocked: tim. Suggest closing/superseding this issue (and #191–#194) with a new spec around option 1, unless you want to explore #2 first.