ElBruno.LocalLLMs 0.20.11 ships AssemblyVersion 0.20.9.0, breaking BlazorComponents/Rag 0.20.11 at startup

[elbruno]

Summary

The ElBruno.LocalLLMs 0.20.11 NuGet package ships ElBruno.LocalLLMs.dll stamped with
AssemblyVersion 0.20.9.0, while the sibling packages released at the same time
(ElBruno.LocalLLMs.BlazorComponents and ElBruno.LocalLLMs.Rag 0.20.11) were compiled against
ElBruno.LocalLLMs, Version=0.20.11.0.

.NET rolls assembly references forward but never backward, so the reference cannot bind and
any app that uses the core package together with BlazorComponents or Rag crashes at startup.

Impact

Hard startup crash, no graceful degradation:

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly
'ElBruno.LocalLLMs, Version=0.20.11.0, Culture=neutral, PublicKeyToken=null'.
The system cannot find the file specified.
File name: 'ElBruno.LocalLLMs, Version=0.20.11.0, Culture=neutral, PublicKeyToken=null'
   at ElBruno.LocalLLMs.BlazorComponents.Extensions.BlazorComponentsServiceExtensions.AddLocalLLMsBlazorComponents(IServiceCollection services, Action`1 configure)
   at Program.<Main>$(String[] args)

The message is misleading — the file is present in the output folder; it is the version
downgrade that fails to bind.

Evidence

Reading AssemblyVersion straight out of the packages in ~/.nuget/packages:

Package	Package version	AssemblyVersion
ElBruno.LocalLLMs	0.20.9	0.20.9.0 ✅
ElBruno.LocalLLMs.BlazorComponents	0.20.9	0.20.9.0 ✅
ElBruno.LocalLLMs	0.20.10	0.20.10.0 ✅
ElBruno.LocalLLMs.BlazorComponents	0.20.10	0.20.10.0 ✅
ElBruno.LocalLLMs	0.20.11	0.20.9.0 ❌
ElBruno.LocalLLMs.BlazorComponents	0.20.11	0.20.11.0 ✅
ElBruno.LocalLLMs.Rag	0.20.11	0.20.11.0 ✅

Reproduce:

$root = "$env:USERPROFILE\.nuget\packages"
foreach ($v in '0.20.9','0.20.10','0.20.11') {
  foreach ($p in 'elbruno.localllms','elbruno.localllms.blazorcomponents') {
    $f = Get-ChildItem "$root\$p\$v\lib\*\*.dll" -ErrorAction SilentlyContinue | Select-Object -First 1
    if ($f) {
      $n = [System.Reflection.AssemblyName]::GetAssemblyName($f.FullName)
      "{0,-40} pkg={1,-8} AssemblyVersion={2}" -f $p, $v, $n.Version
    }
  }
}

Note the FileVersion is also 0.20.9.0, so it looks like the version stamp was not
propagated to the core project for this release (the release was cut from a branch/state where
Version/VersionPrefix was still 0.20.9, or the property is only applied to the satellite
projects).

Steps to reproduce

1. Create a .NET 8/10 Blazor Server app.
2. dotnet add package ElBruno.LocalLLMs --version 0.20.11
3. dotnet add package ElBruno.LocalLLMs.BlazorComponents --version 0.20.11
4. Call builder.Services.AddLocalLLMsBlazorComponents(); in Program.cs.
5. dotnet run → FileNotFoundException before the host starts.

Expected

All packages published under the same release stamp a matching AssemblyVersion, so
ElBruno.LocalLLMs 0.20.11 exposes AssemblyVersion 0.20.11.0.

Suggested fix

• Set Version / VersionPrefix in Directory.Build.props (or a shared Versions.props) so
  every packable project — including ElBruno.LocalLLMs itself — is stamped from one source.

• Add a release check that fails if any packed assembly's AssemblyVersion does not match its
  package version. A few lines are enough:

  Get-ChildItem artifacts\*.nupkg | ForEach-Object { <# expand, compare AssemblyName.Version to package version #> }

• Consider setting <AssemblyVersion>$(VersionPrefix)</AssemblyVersion> explicitly rather than
  relying on the default derivation, since a stale AssemblyVersion is invisible in
  dotnet list package and only shows up at runtime.

Workaround for consumers

Until a fixed package ships, an AssemblyLoadContext.Default.Resolving handler registered from
a [ModuleInitializer] (so it runs before Main is JIT-compiled) can bind the request to the
DLL that is actually in the output folder:

internal static class LocalLLMsAssemblyVersionShim
{
    private const string AssemblyName = "ElBruno.LocalLLMs";

    [ModuleInitializer]
    internal static void Initialize() => AssemblyLoadContext.Default.Resolving += Resolve;

    private static Assembly? Resolve(AssemblyLoadContext context, AssemblyName requested)
    {
        if (!string.Equals(requested.Name, AssemblyName, StringComparison.OrdinalIgnoreCase))
            return null;

        var path = Path.Combine(AppContext.BaseDirectory, $"{AssemblyName}.dll");
        if (!File.Exists(path))
            return null;

        var loaded = context.Assemblies.FirstOrDefault(
            a => string.Equals(a.GetName().Name, AssemblyName, StringComparison.OrdinalIgnoreCase));

        return loaded ?? context.LoadFromAssemblyPath(path);
    }
}

Environment

• .NET SDK 10.0.400-preview
• Windows 11 x64
• Consumer: elbruno/ElBruno.MagenticUI (Blazor Server + Aspire)

[elbruno]

Fixed and verified in v0.21.0 (published to NuGet.org).

Root cause

Directory.Build.props did not derive AssemblyVersion/FileVersion from the package version for the core ElBruno.LocalLLMs project, so a stale version stamp could ship independently of the sibling packages.

Fix

• Directory.Build.props now centrally derives Version/PackageVersion/AssemblyVersion/FileVersion for all four packable projects (ElBruno.LocalLLMs, .Rag, .BitNet, .BlazorComponents), so they can never drift again.
• Added scripts/Validate-PackageAssemblyVersions.ps1, wired into the publish workflow, which fails the release if any packed assembly's version doesn't match its package version.
• Added scripts/Set-ReleaseVersion.ps1 / scripts/Validate-ReleaseVersion.ps1 to keep the version, README What's New, and docs/CHANGELOG.md in sync on every release going forward.

Release history

• v0.20.12 shipped the fix but got stuck on NuGet.org's ingestion pipeline (push accepted, ~1hr propagation delay to the public indexes) — confirmed it did eventually land.
• v0.21.0 is a clean re-publish with no additional code changes, done for a fast, unambiguous fix once 0.20.12 looked stuck.

Consumer validation (reproduces the original repro steps)

Built a minimal console app referencing the published NuGet packages ElBruno.LocalLLMs 0.21.0, ElBruno.LocalLLMs.BlazorComponents 0.21.0, and ElBruno.LocalLLMs.Rag 0.21.0, calling services.AddLocalLLMs(); services.AddLocalLLMsBlazorComponents(); and building the ServiceProvider — the exact call chain from the original stack trace.

Result: builds and runs cleanly, no FileNotFoundException. Confirmed both DLLs resolved from the NuGet cache report AssemblyVersion 0.21.0.0.

Run output:

OK: services registered and provider built without FileNotFoundException.