Skip to content

Bump Microsoft.AI.Foundry.Local 0.3.0 -> 1.1.0 (needs API migration)#17514

Draft
joperezr wants to merge 1 commit into
mainfrom
joperezr/bump-foundry-local-1.1.0
Draft

Bump Microsoft.AI.Foundry.Local 0.3.0 -> 1.1.0 (needs API migration)#17514
joperezr wants to merge 1 commit into
mainfrom
joperezr/bump-foundry-local-1.1.0

Conversation

@joperezr
Copy link
Copy Markdown
Member

Note

Draft — does not build. Posting this PR to coordinate the migration work. Splitting it out of #17056 so the rest of the deferred dep bumps can land.

What's here

A single one-line bump in Directory.Packages.props:

- <PackageVersion Include="Microsoft.AI.Foundry.Local" Version="0.3.0" />
+ <PackageVersion Include="Microsoft.AI.Foundry.Local" Version="1.1.0" />

Why this needs a focused PR

Microsoft.AI.Foundry.Local 1.1.0 is a complete API redesign, not an additive release. The whole FoundryLocalManager pattern changes:

Old (0.3.0) New (1.1.0)
Injected instance (FoundryLocalManager via DI) Static singleton (FoundryLocalManager.Instance, CreateAsync)
manager.IsServiceRunning (sync property) (new health pattern, TBD)
manager.StartServiceAsync(ct) StartWebServiceAsync with Urls property
manager.Endpoint (property) Urls[0] (after web service start)
manager.ApiKey (unclear in new API)
manager.ListLoadedModelsAsync(ct) navigate via GetCatalogAsync()Catalog.GetModelAsync()
manager.DownloadModelWithProgressAsync(model, ct) model.DownloadAsync()
manager.LoadModelAsync(modelId, ct) model.LoadAsync()

Files that need migrating

  • src/Aspire.Hosting.Foundry/FoundryLocalHealthCheck.csmanager.IsServiceRunning
  • src/Aspire.Hosting.Foundry/LocalModelHealthCheck.csmanager.ListLoadedModelsAsync
  • src/Aspire.Hosting.Foundry/FoundryExtensions.csApiKey, StartServiceAsync, Endpoint, DownloadModelWithProgressAsync, LoadModelAsync (8 call sites)
  • DI registration in AddFoundryLocal will likely change (singleton vs scoped, no longer registering the manager as a service)
  • Lifecycle/disposal — FoundryLocalManager is now IDisposable with explicit CreateAsync/Dispose and singleton ownership

Why I'm not just doing it

The migration is large enough to deserve product judgement (DI shape, lifecycle, behavior in the AppHost) rather than a mechanical port. Tagging @tommasodotNET and @sebastienros — you've been closest to the Foundry hosting code recently; can you take a look at how you'd like to adapt this?

The latest SDK README is helpful here: https://www.nuget.org/packages/Microsoft.AI.Foundry.Local/1.1.0

Related

This bump intentionally does not build. Microsoft.AI.Foundry.Local 1.1.0 is a complete API redesign and src/Aspire.Hosting.Foundry needs to be migrated before this can land. Tracking it here as a draft so we have a single place to coordinate the migration.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions
Copy link
Copy Markdown
Contributor

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17514

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17514"

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant