Describe the bug
The published NuGet package Sdcb.PaddleOCR.Models.Local 3.3.1 has a compiled IL reference to Sdcb.PaddleOCR.Models.LocalV5, Version=3.0.0.0 (confirmed via its .nuspec: <dependency id="Sdcb.PaddleOCR.Models.LocalV5" version="3.0.0" exclude="Build,Analyzers" />), while the assembly you actually need at runtime for LocalFullModels.LatinV5 (and the other new PP-OCRv5 language models added in 3.3.x) is Sdcb.PaddleOCR.Models.LocalV5 3.3.1.0 — LocalV5 3.0.0 doesn't even embed the corresponding model resources (e.g. latin_PP-OCRv5_mobile_rec).
For plain/unsigned consumption this mismatch is silently tolerated by the CLR (weak-named assemblies are resolved by simple name, version is ignored). But for any consumer that strong-names/GAC-deploys the dependency chain (e.g. via StrongNamer or similar re-signing), .NET Framework's Fusion loader enforces exact version matching on the reference, and this stale 3.0.0 dependency turns into a hard FileLoadException/FileNotFoundException at runtime, fixable only via an assembly-binding redirect.
I found that this was already fixed in source, but the fix apparently never made it into a published release:
commit f604811e1b991e874c27565fcdabf85815ceb035
Author: sdcb <sdflysha@qq.com>
Date: 2026-05-26 22:33:33 +0800
update release package
- <PackageReference Include="Sdcb.PaddleOCR.Models.LocalV5" Version="3.0.0" />
+ <PackageReference Include="Sdcb.PaddleOCR.Models.LocalV5" Version="3.3.1" />
- <PackageReference Include="Sdcb.PaddleOCR" Version="3.0.1" />
+ <PackageReference Include="Sdcb.PaddleOCR" Version="3.3.1" />
(merged to master via 6a004e0, "merge from feature/3.3", same day)
This commit bumps Sdcb.PaddleOCR.Models.Local's dependency on LocalV5 (and Sdcb.PaddleOCR) to 3.3.1, matching what the package actually needs — but since NuGet doesn't allow republishing under the same version number, the package currently live on nuget.org as 3.3.1 still predates this fix.
Could you publish a new patch release (e.g. 3.3.2) of Sdcb.PaddleOCR.Models.Local built from master after f604811? That would let consumers who strong-name/GAC their dependencies avoid needing a binding redirect workaround just to load LocalFullModels.LatinV5.
Happy to provide more repro details (assembly metadata dumps, etc.) if useful.
Steps to reproduce the bug
Steps to Reproduce
Minimal repro without even needing strong-naming — just inspect the package metadata:
dotnet new classlib -f net48 -o repro
- Add explicit references (so NuGet doesn't just float to whatever satisfies the range):
dotnet add repro package Sdcb.PaddleOCR.Models.Local -v 3.3.1
dotnet add repro package Sdcb.PaddleOCR.Models.LocalV5 -v 3.3.1
- Inspect the installed
Sdcb.PaddleOCR.Models.Local package's .nuspec
(%userprofile%\.nuget\packages\sdcb.paddleocr.models.local\3.3.1\sdcb.paddleocr.models.local.nuspec):
<dependency id="Sdcb.PaddleOCR.Models.LocalV5" version="3.0.0" exclude="Build,Analyzers" />
— declared minimum is 3.0.0, but the assembly reference compiled into Sdcb.PaddleOCR.Models.Local.dll is pinned to exactly Version=3.0.0.0 (check with ildasm / monodis / dotnet-ildasm on the .dll, look at the .assembly extern Sdcb.PaddleOCR.Models.LocalV5 entry), while the Sdcb.PaddleOCR.Models.LocalV5.dll you actually get at 3.3.1 reports Version=3.3.1.0 (.assembly Sdcb.PaddleOCR.Models.LocalV5 self-header) and is the only one that contains the PP-OCRv5 language model resources (latin_PP-OCRv5_mobile_rec, arabic_PP-OCRv5_mobile_rec, etc.) needed by LocalFullModels.LatinV5 and friends.
To reproduce the actual runtime failure (not just the metadata mismatch):
- In the same
net48 project, strong-name-sign all referenced assemblies at build time — e.g. add <PackageReference Include="StrongNamer" Version="0.2.4" /> (this is the common workaround for consumers that need to deploy into the GAC, since the CLR refuses to let a strongly-named/GAC assembly statically reference an unsigned one).
- Build, then call anything that touches
LocalFullModels.LatinV5 (e.g. new PaddleOcrAll(LocalFullModels.LatinV5)).
- Observe:
System.IO.FileLoadException: Could not load file or assembly 'Sdcb.PaddleOCR.Models.LocalV5, Version=3.0.0.0, Culture=neutral, PublicKeyToken=...'
(or FileNotFoundException, depending on probing), thrown from inside Sdcb.PaddleOCR.Models.Local's static reference to the wrong LocalV5 version. The only way to make it load is to add an app.config <bindingRedirect oldVersion="0.0.0.0-3.3.1.0" newVersion="3.3.1.0" /> for Sdcb.PaddleOCR.Models.LocalV5 — which shouldn't be necessary once the dependency declaration itself is correct (as already fixed on master in f604811).
Expected behavior
No response
Screenshots
No response
Release version
No response
IDE
No response
OS version
No response
Additional context
No response
Describe the bug
The published NuGet package
Sdcb.PaddleOCR.Models.Local3.3.1 has a compiled IL reference toSdcb.PaddleOCR.Models.LocalV5, Version=3.0.0.0(confirmed via its.nuspec:<dependency id="Sdcb.PaddleOCR.Models.LocalV5" version="3.0.0" exclude="Build,Analyzers" />), while the assembly you actually need at runtime forLocalFullModels.LatinV5(and the other new PP-OCRv5 language models added in 3.3.x) isSdcb.PaddleOCR.Models.LocalV53.3.1.0 —LocalV53.0.0 doesn't even embed the corresponding model resources (e.g.latin_PP-OCRv5_mobile_rec).For plain/unsigned consumption this mismatch is silently tolerated by the CLR (weak-named assemblies are resolved by simple name, version is ignored). But for any consumer that strong-names/GAC-deploys the dependency chain (e.g. via
StrongNameror similar re-signing), .NET Framework's Fusion loader enforces exact version matching on the reference, and this stale3.0.0dependency turns into a hardFileLoadException/FileNotFoundExceptionat runtime, fixable only via an assembly-binding redirect.I found that this was already fixed in source, but the fix apparently never made it into a published release:
(merged to
mastervia6a004e0, "merge from feature/3.3", same day)This commit bumps
Sdcb.PaddleOCR.Models.Local's dependency onLocalV5(andSdcb.PaddleOCR) to3.3.1, matching what the package actually needs — but since NuGet doesn't allow republishing under the same version number, the package currently live on nuget.org as3.3.1still predates this fix.Could you publish a new patch release (e.g.
3.3.2) ofSdcb.PaddleOCR.Models.Localbuilt frommasterafterf604811? That would let consumers who strong-name/GAC their dependencies avoid needing a binding redirect workaround just to loadLocalFullModels.LatinV5.Happy to provide more repro details (assembly metadata dumps, etc.) if useful.
Steps to reproduce the bug
Steps to Reproduce
Minimal repro without even needing strong-naming — just inspect the package metadata:
dotnet new classlib -f net48 -o reproSdcb.PaddleOCR.Models.Localpackage's.nuspec(
%userprofile%\.nuget\packages\sdcb.paddleocr.models.local\3.3.1\sdcb.paddleocr.models.local.nuspec):3.0.0, but the assembly reference compiled intoSdcb.PaddleOCR.Models.Local.dllis pinned to exactlyVersion=3.0.0.0(check withildasm/monodis/dotnet-ildasmon the.dll, look at the.assembly extern Sdcb.PaddleOCR.Models.LocalV5entry), while theSdcb.PaddleOCR.Models.LocalV5.dllyou actually get at3.3.1reportsVersion=3.3.1.0(.assembly Sdcb.PaddleOCR.Models.LocalV5self-header) and is the only one that contains the PP-OCRv5 language model resources (latin_PP-OCRv5_mobile_rec,arabic_PP-OCRv5_mobile_rec, etc.) needed byLocalFullModels.LatinV5and friends.To reproduce the actual runtime failure (not just the metadata mismatch):
net48project, strong-name-sign all referenced assemblies at build time — e.g. add<PackageReference Include="StrongNamer" Version="0.2.4" />(this is the common workaround for consumers that need to deploy into the GAC, since the CLR refuses to let a strongly-named/GAC assembly statically reference an unsigned one).LocalFullModels.LatinV5(e.g.new PaddleOcrAll(LocalFullModels.LatinV5)).FileNotFoundException, depending on probing), thrown from insideSdcb.PaddleOCR.Models.Local's static reference to the wrongLocalV5version. The only way to make it load is to add anapp.config<bindingRedirect oldVersion="0.0.0.0-3.3.1.0" newVersion="3.3.1.0" />forSdcb.PaddleOCR.Models.LocalV5— which shouldn't be necessary once the dependency declaration itself is correct (as already fixed onmasterinf604811).Expected behavior
No response
Screenshots
No response
Release version
No response
IDE
No response
OS version
No response
Additional context
No response