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
| Layer | Technology | Notes |
|---|
| Runtime | .NET 10 | LTS release |
| Public API | ASP.NET Core 10 Minimal APIs | Registry endpoints only |
| Web UI | Blazor SSR + Interactive Server | See Frontend Implementation |
| Admin API | OData Restier via EasyAF | Internal only; not on public surface |
| ORM | EF Core 10 (Database-First) | Entities generated by EasyAF tooling |
| Database schema | SQL Server Database Project (.sqlproj) | Source of truth for schema |
| Auth | GitHub OAuth + PBKDF2 API keys + OIDC | Port existing PBKDF2 system |
| Storage | Azure Blob Storage | Existing abstraction renamed .nupkg → .aipkg |
| Search | Azure AI Search | New AipkgSearchDocument model |
| DI | ASP.NET Core built-in DI | Autofac removed |
| Config | appsettings.json + environment variables | No custom XML config |
| CDN | Azure CDN | Keep existing stats parsing jobs |
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.
| Category | Items to Delete |
|---|
| V2/OData public API | All ODataV1, ODataV2 controllers and routes |
| OWIN | All OWIN startup, middleware, and pipeline code |
| Autofac | All Autofac container setup, modules, and registrations |
| Razor views | All .cshtml files, _ViewImports, _Layout, tag helpers |
| jQuery / Bootstrap scripts | All .js and .css bundle files from old MVC stack |
| Symbol packages | NuGet.Services.Symbols.*, all snupkg handling code |
| Functional tests | NuGetGallery.FunctionalTests.sln and related projects |
| Python tooling | All .py scripts in the repo |
| Legacy migrations | EF migration history predating the SLNX rewrite |
What to Keep and Adapt
| Category | Keep | Adaptation |
|---|
| V3 API logic | Registration, flatcontainer, search, push, autocomplete | Rename, update schemas |
| CDN stats jobs | src/Stats.* | Adapt for .aipkg download events |
| GitHub vulnerability jobs | src/GitHubVulnerabilities2Db/ | Adapt package ID resolution |
| PBKDF2 API key system | Auth/ApiKeyV4 logic | Port to new project |
| Azure Blob storage abstraction | ICoreFileStorageService | Rename types |
| Azure AI Search integration | NuGet.Services.AzureSearch | New document model |
| License scanning jobs | src/NuGet.Jobs.Validation.PackageSigning.* | Evaluate; lower priority |