fix(879): resolve the unsatisfiable netstandard 2.1.0.0 bind that breaks Deedle in the add-in

[drmoisan]

fix(879): resolve the unsatisfiable netstandard 2.1.0.0 bind that breaks Deedle in the add-in

Summary

• Adds UtilitiesCS.Bootstrap.AssemblyBindingFallback, a host-neutral assembly-resolution ladder that satisfies a netstandard 2.1.0.0 request with the 2.0.0.0 facade the machine actually has, and installs it eagerly from the ThisAddIn static constructor so it is in place before any ribbon handler runs.
• Adds a declarative netstandard binding redirect to TaskMaster/app.config as defence in depth, so the add-in is hardened whether or not the managed fallback is reached first.
• Adds a child-AppDomain regression harness that reproduces the reported production failure and a fail-before/pass-after pair proving the remedy, rather than asserting it.
• Adds 21 unit tests across two classes covering every ladder rung, its guards, and its boundary behaviour, bringing the new module to 94.03% line coverage.
• Records the underlying root cause as a separate tracked issue; this PR makes the add-in robust to it but does not remove it.

Why

The maintainer reported that clicking the QuickFiler ribbon button in a fresh Outlook session raised a TypeInitializationException from Deedle.Reflection, chaining through <StartupCode$Deedle>.$FrameUtils to a FileNotFoundException for netstandard, Version=2.1.0.0. The QuickFiler data model did not populate.

netstandard 2.1.0.0 does not exist for .NET Framework on any machine, so that request can never be satisfied by probing. The request does not originate in Deedle: Deedle.dll 3.0.0.0 references netstandard 2.0.0.0. It originates in FSharp.Core.

The FSharp.Core.11.0.100 package ships two binaries, lib/netstandard2.0 and lib/netstandard2.1, and this solution's HintPath entries are split between them. The netstandard2.1 binary references netstandard 2.1.0.0 and is therefore unloadable wherever it is deployed. Which binary lands in a given output directory is last-writer-wins build ordering, so a project can move between working and broken across a rebuild with no source change.

This PR does not change those HintPath entries. That work is tracked separately, and the two remedies are complementary: the separate issue removes the unloadable binary, while this PR makes the add-in tolerate whichever binary is present.

What Changed

Core fix

• UtilitiesCS/Bootstrap/AssemblyBindingFallback.cs — new. A four-rung resolution ladder behind five injected delegates, with a [ThreadStatic] re-entrance guard, an Interlocked.Exchange idempotence guard on Install(), and a boundary catch so no exception reaches the CLR binder. References no WinForms type, no Outlook Interop type, and no logging framework.
• TaskMaster/ThisAddIn.cs — adds an explicit static constructor whose body is a single AssemblyBindingFallback.Install() call. The eager installation point matters: the failure occurs on the first ribbon click, before any lazier hook would run.
• TaskMaster/app.config — adds a netstandard dependentAssembly redirecting 0.0.0.0-2.1.0.0 to 2.0.0.0.

Tests

• UtilitiesCS.Test/Bootstrap/AssemblyBindingFallbackTests.cs — 11 tests driving every rung through injected delegates.
• UtilitiesCS.Test/Bootstrap/AssemblyBindingFallbackEdgeCaseTests.cs — 10 tests covering the guard clauses, the rung-local catch blocks, and the probe-directory rung.
• TaskMaster.Test/Bootstrap/ChildDomainBindProbe.cs and NetstandardBindChildDomainTests.cs — a MarshalByRefObject probe and a nine-test harness that creates child AppDomains, performs each assertion inside the domain, and marshals primitives back.
• TaskMaster.Test/Bootstrap/AddInEagerInstallShapeTests.cs — guards the eager install point and the config redirect against silent deletion, by reflection and XML assertion rather than by prose search.

Project files

Four Compile Include registrations only. These projects use explicit compile items with no wildcard glob, so an unregistered file silently does not build. No HintPath, reference, or property was changed.

Architecture / How It Fits Together

ThisAddIn's static constructor calls AssemblyBindingFallback.Install(), which subscribes a handler to AppDomain.CurrentDomain.AssemblyResolve exactly once. When the CLR fails to bind a name, the handler consults a ladder that tries, in order: an already-loaded assembly whose identity matches; a load by full display name; a load from the runtime directory; and a load from the add-in's own probe directory. Each rung absorbs its own failures and declines, so a miss is null rather than a thrown exception, which is what the ResolveEventHandler contract requires.

Every external dependency is an injected delegate, so the ordering logic is unit-testable without touching the GAC or the filesystem. The production wiring is supplied by a single factory.

Verification

Completed

• Full toolchain in repository order, all four steps passing in one clean pass with no restart: CSharpier format then check at the fixpoint; .NET analyzers with EnableNETAnalyzers and EnforceCodeStyleInBuild at 0 warnings and 0 errors; nullable analysis with TreatWarningsAsErrors at 0 warnings and 0 errors; and the full suite at 7293 passed, 0 failed.
• The analyzer and nullable gates were confirmed non-vacuous: CoreCompile was skipped on zero projects, so the analyzers actually ran.
• Fail-before: against a build containing no fix, the harness recorded DEEDLE_RECORD_CONVERSION_OUTCOME=NETSTANDARD-BIND-FAILURE:TypeInitializationException.
• Pass-after: against the fixed build, the same probe recorded INVOKED-NO-EXCEPTION.
• Both readings were taken in a child domain whose ApplicationBase is verified by its own passing assertion, and the negative control — that netstandard 2.1.0.0 still throws in an installer-free domain — passed in both runs, so the positive result is attributable to the fix rather than to a loss of isolation.
• New-module line coverage 189 of 201 lines, 94.03%, against the 90% floor the acceptance criteria state.
• No new netstandard.dll entered any project or output directory, and the FSharp.Core redirect count is unchanged from baseline.

Recommended

• A fresh Outlook session: click the QuickFiler ribbon button without first opening any SVG-bearing surface, and confirm Deedle loads and the data model populates. This is a human gate and is not discharged by this PR.

Backward Compatibility / Migration Notes

No public API is removed or renamed. All source changes are additive except the eager install point, the config redirect, and four compile-item registrations. The resolution handler only participates when the CLR has already failed to bind a name, so it cannot change the outcome of a binding that previously succeeded.

Risks and Mitigations

• The reported production trace also contains an unexplained 2.0.0.0 frame. This PR does not explain it. A measurement taken during this work shows that in an installer-free child domain on this machine, netstandard 2.0.0.0 binds successfully while 2.1.0.0 throws, which localises the open question to the add-in AppDomain rather than the machine. This issue should not be considered closed on a 2.1.0.0 result alone.
• The add-in output directory currently receives the loadable FSharp.Core binary, which is build-order luck rather than correctness. It can move back to the unloadable one on any rebuild. That is the separately tracked root cause; this PR's remedy does not depend on which binary is present.
• The manual live-Outlook verification is not performed. The corresponding acceptance criterion is deliberately left unchecked rather than marked delivered.

Review Guide

Suggested order:

1. UtilitiesCS/Bootstrap/AssemblyBindingFallback.cs — the whole fix is here.
2. TaskMaster/ThisAddIn.cs and TaskMaster/app.config — the two wiring points.
3. TaskMaster.Test/Bootstrap/NetstandardBindChildDomainTests.cs — the harness, including the negative control and the isolation assertions that make its positive results meaningful.
4. The two UtilitiesCS.Test classes — mechanical, delegate-driven, and safe to skim.

The diff is 2096 insertions and 0 deletions across 11 source files, so there is no mechanical move or rename to work around.

Follow-ups

• Align the split FSharp.Core HintPath entries on the loadable binary, and consider a build-time guard asserting that no deployed FSharp.Core references netstandard 2.1.0.0. Tracked separately.
• Resolve the open 2.0.0.0 question in the production trace.

GitHub Auto-close

• None. The manual live-Outlook acceptance criterion is not discharged, and the PR context reports no verified closing issues, so no closing keyword is emitted.

Acceptance criteria: merging at 18 of 19, with AC19 withheld

This change merges with 18 of 19 acceptance criteria checked. AC19 is not checked, and the
check-off is withheld pending the maintainer.

AC19 requires a live Outlook session. No Outlook session was started, and nothing about the
criterion was simulated, approximated, or inferred from a proxy. Task [P6-T24] therefore withheld
the check-off rather than discharging it, and spec.md line 554 remains - [ ] with an explicit
Check-Off Withheld: record beside it. The criterion is undischarged, not satisfied.

This follows the pattern already established in this run for a criterion that cannot be discharged
by an automated agent: merge the verified work, leave the box unchecked, state the gap plainly in
the body, and leave the discharge to the maintainer.

A correction to this change's own stated diagnosis

This item was halted and replanned on the premise that AC10 was a vacuous acceptance
criterion — one that passed against a build containing no fix. That premise was wrong, and it is
recorded here rather than quietly dropped.

AC10 was never vacuous. The probe was rooted in a directory that could not reproduce the
defect. FSharp.Core.11.0.100 ships two binaries and this solution's HintPath entries are split
between them; TaskMaster.Test/bin/Debug received the loadable flavour, so nothing rooted there
ever requests netstandard 2.1.0.0 and every probe rooted there passes regardless of the fix.
Rooted correctly, all three probe designs reproduce the failure, including the original design
that was dismissed as vacuous.

The requirement that drove this out was the demand for a demonstrated pre-fix failure rather than an
argued one. That requirement was invoked for a reason that turned out to be incorrect, and it
surfaced the true cause anyway. The general lesson stands independently of this item: a criterion
that has never been observed failing is unproven, and demanding the failure be shown is cheaper than
arguing about whether it would occur.

The underlying HintPath split is filed separately as issue #895 with the measured evidence. It is
out of scope here because the affected project files may be owned by sibling items in the same
parallel run.