B3.Blicks.Resolver

The Blick delivery library a B3 app shell runs at startup. It turns a set of selected versions + a feed into loaded Blicks: resolve package versions against NuGet, download each Blick and its dependency closure, verify content hashes (fail-closed), lay out static web assets, and load each Blick into its own isolated, non-collectible AssemblyLoadContext — returning a catalog the shell wires into the Blazor router and DI. Selection-source-agnostic — it never decides which Blicks to run (the selected versions) or where they come from (the supplied sources).

Usage

var selectedVersions = SelectedVersions.Of(
    ("B3.Blicks.ReportsSample.Blick", "[2.0.0,3.0.0)"),
    ("B3.Blicks.NotesSample.Blick",   "1.1.*"));

var options = new ResolverOptions
{
    Sources         = [ new BlickServerSource("https://api.blicks.b3soft.net", apiKey: blickKey) ],   // the proprietary BlickServer registry (dev: api.blicks-dev.b3soft.net)
    CacheDirectory  = "/var/cache/b3-blicks",     // scratch dir for the current run; pods are stateless (not an availability mechanism)
    LayoutDirectory = "/var/lib/b3-blicks",
    Logger          = myErrorLogger,              // optional; a no-op is used when null
    // FailFast = true, RequireContentHash = true (production defaults)
};

LoadedBlickSet set = await new BlickResolver().ResolveAndLoad(selectedVersions, options);

// Wire the shell:
//   router.AdditionalAssemblies   = set.Assemblies
//   endpoints.AddAdditionalAssemblies(set.Assemblies)
//   foreach blick: blick.ConfigureServices(services)
//   startupProbe -> set.IsReady

LocalPathSource("/path/to/packages") swaps the feed for a folder of .nupkg files (or loose {Assembly}.dlls) in the dev loop — same shape, offline.

Behaviour

• Resolve exact (2.0.0), floating (2.0.*), range ([2.0.0,3.0.0)), and prerelease (2.1.0-preview.3) package versions via NuGet.Protocol.
• Verify each downloaded .nupkg against the feed-provided content hash (base64 SHA-512) before it is ever loaded; a mismatch — or a missing-but-required hash — throws and the bytes are not loaded.
• Download packages once per run; downloads run in parallel. The CacheDirectory is run-scoped scratch — pods are stateless, so it is not a cross-restart last-known-good store and not the availability mechanism (availability comes from running replicas of the feed + B3.Configuration). The on-disk layout is reused within a run when a .blick-version marker shows the resolved version is already extracted, so a retry skips re-extraction.
• Auth to a private feed via FeedCredential(Username, Password) (HTTP basic, attached to every feed request). A feed that gates reads behind a key exposes it as the basic-auth password — there is no v3 read protocol that authenticates a download with a bare API key (that header is push-only).
• Isolate each Blick in its own non-collectible AssemblyLoadContext: the runtime, ASP.NET Core/Blazor, and B3.Blicks.Contracts are shared (single type identity); private third-party dependencies are isolated, so two Blicks with conflicting transitive versions do not clash. No hot-unload — updates happen by restart.
• Fail-fast: with FailFast on, an undeliverable selection throws so the pod crashloops (the startupProbe never goes green) rather than starting with a partial Blick set.

Public API

SelectedVersions / SelectedVersion · ResolverOptions · FeedCredential · BlickSource (FeedSource, LocalPathSource) · BlickResolver.ResolveAndLoad(selectedVersions, options) : Task<LoadedBlickSet> · LoadedBlickSet (Assemblies, Blicks, NavItems, Widgets, IsReady, Unresolved) · LoadedBlick · BlickLoadContext · BlickHashMismatchException · BlickResolutionException.