The AI•Pkg server is derived from NuGetGallery but radically simplified. The public surface exposes only a JSON API under /v3/. OData V2, OWIN, Autofac, and all Razor view infrastructure are removed.
Technology Stack
Rationale
Why .NET 10 (not .NET 9)
.NET 10 is the next LTS release and will be the stable foundation for the duration of Phase 0–4. Starting on LTS avoids an in-project upgrade mid-migration.
Why Minimal APIs (not Controllers)
NuGetGallery used MVC controllers with complex filter pipelines. Minimal APIs are explicit, AOT-friendly, and map directly to the endpoint-per-file structure used in the new AI•Pkg.Server/Api/V3/ directory.
Why EasyAF (not hand-written EF migrations)
The NuGetGallery migration history is ~200 migrations deep and contains schema changes we’re discarding. Starting from a .sqlproj as the schema source of truth means:
- No migration history cruft
- Schema is auditable by any SQL developer, not just .NET developers
- Schema publishes are idempotent (dacpac deployment)
- Entity classes are regenerated, not hand-maintained
Why Blazor SSR (not Next.js, React, etc.)
Single .NET 10 stack: the team already owns C# and the V3 API is in the same process. No separate frontend build pipeline, no CORS concerns for authenticated pages, no hydration mismatches.
Why Azure AI Search (not Elasticsearch, Typesense, etc.)
NuGetGallery already has a mature Azure AI Search integration in NuGet.Services.AzureSearch. The port is a schema adaptation, not a rewrite.
What to Delete from NuGetGallery
These items will not exist in the AI•Pkg repo. Delete them when setting up the fork.
What to Keep and Adapt