Skip to content

Sdcb.PaddleOCR.Models.Local 3.3.1 on NuGet references LocalV5 3.0.0, causing strong-name version-binding failures — please cut a new release #191

Description

@SergeyKlevtsov

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.0LocalV5 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:

  1. dotnet new classlib -f net48 -o repro
  2. 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
    
  3. 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):

  1. 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).
  2. Build, then call anything that touches LocalFullModels.LatinV5 (e.g. new PaddleOcrAll(LocalFullModels.LatinV5)).
  3. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions