net472: strong-named NPOI.Core cannot load unsigned ExcelFinancialFunctions — all financial functions throw FileLoadException

[ken-swyfft]

NPOI Version

master (unreleased). Introduced by #1808, merged 2026-04-17 (0fc7bb25).

Released versions are not affected — 2.8.0 shipped 2026-04-06, before #1808, and does not list ExcelFinancialFunctions in any dependency group. This is a heads-up before the next release.

File Type

• OTHER — build/packaging issue, not file-format specific

Issue Description

On net472, every financial function throws at runtime:

System.IO.FileLoadException : Could not load file or assembly
'ExcelFinancialFunctions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies. A strongly-named assembly is required.
(Exception from HRESULT: 0x80131044)

main/NPOI.Core.csproj sets SignAssembly=true (../npoi.snk) and targets net472. #1808 added a PackageReference to ExcelFinancialFunctions 3.0.0, whose assembly is not strong-named (PublicKeyToken=null). .NET Framework forbids a strong-named assembly from binding to an unsigned dependency, so the load fails at runtime.

.NET Core / .NET 5+ dropped strong-name identity checks, which is why every net10.0 test assembly is green and only net472 fails.

This affects all net472 consumers regardless of whether they sign their own assemblies — the failing link is NPOI.Core → ExcelFinancialFunctions, independent of the caller.

The reference has no PrivateAssets="all" Pack="false" (unlike the SkiaSharp entries alongside it), so it will flow into the published package as a real dependency for the .NETFramework4.7.2 group.

Reproduce Steps

Current CI already reproduces it — the windows-latest job on every master push fails with 34 net472 failures in NPOI.TestCases.dll, e.g. run 30535975609 (job 90849260174).

Equivalent minimal repro for a consumer: reference NPOI (built from master) from a net472 project and evaluate any financial formula, e.g. PMT(0.08/12, 20*12, 500).

Scope

Because CLR assembly loading is lazy, the failure only triggers when a financial function actually executes — ordinary formula evaluation on net472 is unaffected. The affected functions are the ones routed through the new engine:

PV FV PMT NPER RATE IRR MIRR XIRR XNPV NPV IPMT PPMT CUMIPMT CUMPRINC DB DDB SLN SYD VDB EFFECT NOMINAL

Why CI didn't flag it

Three things happened to combine, which may be worth addressing independently of the fix:

1. The compile-time warning was suppressed in the same commit. 59d46e7a added <NoWarn>$(NoWarn);CS8002</NoWarn> to main/NPOI.Core.csproj in the same diff that added the package reference. CS8002 is "Referenced assembly does not have a strong name" — precisely this problem.
2. The run-level conclusion hides the failing job. Integrate ExcelFinancialFunctions as backing engine for NPOI financial formula evaluation #1808's final PR run (24537756217) and the post-merge master push (24581212794) both report conclusion: success, while their windows-latest jobs are conclusion: failure. The red job never surfaced as a red check.
3. windows-latest was already red before Integrate ExcelFinancialFunctions as backing engine for NPOI financial formula evaluation #1808, so the 34 new failures blended into existing noise. Per-job status on master runs 24281587961, 24291664324, 24484880085 and 24490962919 (2026-04-11 → 04-16) is windows-latest: failure in all four.

As an aside, #1808's last PR run failed on a different load error in the same netstandard2.0-on-net472 chain (System.Memory, Version=4.0.1.2). That was pinned in 52bc1204 and the PR merged; the strong-name failure only appeared post-merge, so no PR-level run ever displayed it.

Possible fixes

I don't have a strong opinion on which is right for the project, but the options seem to be:

1. Exclude the reference on net472 and keep NPOI's previous managed implementations for that TFM (Condition="'$(TargetFramework)' != 'net472'"), guarding the call sites.
2. Get a strong-named ExcelFinancialFunctions. Upstream is netstandard2.0-only and was last published 2021-12-07, so this looks unlikely without a fork. (Note the project already uses MathNet.Numerics.Signed rather than plain MathNet for the same reason.)
3. Drop SignAssembly for net472 — probably a non-starter, since it would break existing signed consumers.
4. Drop net472 from NPOI.Core's TargetFrameworks.

Whichever route, re-enabling CS8002 (or at least scoping the NoWarn narrowly) would prevent a recurrence, and making the windows-latest job's status visible at the run level would help the next case surface on the PR rather than after merge.

---

Filed by Claude (AI assistant) on behalf of @ken-swyfft. All run IDs, commit SHAs and package metadata above were verified against the GitHub and NuGet APIs; happy to provide the underlying log excerpts.

[ken-swyfft]

Correction to the original report: I wrote above that a strong-named ExcelFinancialFunctions "looks unlikely without a fork." That's wrong, and it understates how easy this is to fix. A signed package already exists on NuGet. Apologies for the misdirection.

fsprojects/ExcelFinancialFunctions added strong-name signing in 838677f4 ("Added strong name signing", 2022-07-30) and published 3.3.0-rc1 the same day. NPOI pins 3.0.0 — the oldest of the 3.x line, and predating the signing work by 8 months.

I downloaded each package and read the token from the assembly metadata rather than relying on release notes:

EFF version	PublicKeyToken
3.0.0 — currently pinned	null (unsigned)
3.2.0	null (unsigned)
3.3.0-rc1	483f7b2ace0336c8 (signed)

[System.Reflection.AssemblyName]::GetAssemblyName($dll).GetPublicKeyToken()

The whole net472 chain is signed with that bump — NPOI.Core (npoi.snk) → ExcelFinancialFunctions 3.3.0-rc1 (483f7b2ace0336c8) → FSharp.Core 6.0.5 (b03f5f7f11d50a3a, netstandard2.0). Note 3.3.0-rc1 moves the FSharp.Core floor from 5.0.0 to 6.0.5.

API compatibility

I extracted every Financial.* member NPOI calls across main/SS/Formula/** (49 distinct methods, spanning FinancialAtpFunctions.cs and the Functions/*.cs implementations) and checked them against the ExcelFinancialFunctions.xml doc shipped inside the 3.3.0-rc1 package, which exposes 57. All 49 are present — consistent with 3.1.0 and 3.2.0 being purely additive per the release notes.

So the fix appears to be one line in Directory.Packages.props:

-    <PackageVersion Include="ExcelFinancialFunctions" Version="3.0.0" />
+    <PackageVersion Include="ExcelFinancialFunctions" Version="3.3.0-rc1" />

The one caveat

3.3.0-rc1 is a prerelease, and 3.3.0 final was never cut — so this means shipping a stable NPOI against a prerelease dependency, which may not be acceptable here. Mitigations, roughly in order of cost:

1. Ask fsprojects to promote 3.3.0 to final. The code has been unchanged for ~4 years, the tag and rc exist, and their #71 "Release 3.3.0" is closed. The repo isn't archived (activity through 2024). This is the cleanest outcome and needs no NPOI code changes.
2. Take the rc1 bump now and move to 3.3.0 final if/when it ships.
3. Make the dependency net472-conditional. Restore the pre-Integrate ExcelFinancialFunctions as backing engine for NPOI financial formula evaluation #1808 implementations for net472 only (git show 59d46e7a^:main/SS/Formula/Functions/Rate.cs etc. — Integrate ExcelFinancialFunctions as backing engine for NPOI financial formula evaluation #1808 replaced working code, so the diff is net-negative for Fv, Pv, Pmt, Nper, Rate, Irr, Mirr, IPMT, PPMT) and leave the 35 ATP functions registered as null on net472 as they were before Integrate ExcelFinancialFunctions as backing engine for NPOI financial formula evaluation #1808. net472 then matches 2.8.0 behaviour exactly — no regression — while .NET Core keeps the full new capability.

On the "port it into NPOI" option I floated earlier: it splits very unevenly, so it's worth stating precisely. The 9 core TVM functions need no porting at all (they're in git history). The 5 new depreciation functions (DB, DDB, SLN, SYD, VDB) are straightforward closed forms, VDB aside. The 35 ATP bond/coupon functions are the real cost — the crux is daycountbasis.fs (30/360 US vs European, actual/actual, coupon-date arithmetic) plus oddbonds.fs and iterative root-finding, and EFF's release history is a decade of accumulated Excel-compatibility corrections that a fresh port would have to rediscover. Given a signed package already exists, that all seems avoidable. EFF is Apache-2.0 (per PackageLicenseExpression in its .fsproj), so a port would at least be licence-compatible if it ever became necessary.

---

Filed by Claude (AI assistant) on behalf of @ken-swyfft. Package tokens, the method cross-reference and the dependency metadata above were all verified locally against the NuGet-published artifacts.

[tonyqus]

If this issue cannot be solved, I have to consider rollback the #1808 change