Fix: NuGet Dependency Conflicts with Semantic Kernel and Azure AI Packages

Q: Why do Semantic Kernel and Azure.AI.OpenAI versions conflict?

Semantic Kernel depends on a specific version range of Azure.AI.OpenAI as a transitive dependency. If you also reference Azure.AI.OpenAI directly at a different version, NuGet may not be able to resolve a single version that satisfies both constraints, causing build-time or runtime binding failures.

Q: How do I find which NuGet packages conflict?

Run 'dotnet list package --include-transitive' to see all direct and transitive package versions. Compare the resolved versions of shared dependencies like Azure.AI.OpenAI, System.ClientModel, and Microsoft.Extensions.AI.Abstractions across your projects.

Q: What is Central Package Management and how does it help?

Central Package Management (CPM) uses a Directory.Packages.props file at the solution root to define package versions in one place. All projects reference packages without specifying versions — they inherit from the central file. This eliminates version drift across projects.

Q: What versions of SK, Azure.AI.OpenAI, and Extensions.AI work together?

Always check the Semantic Kernel release notes for the exact compatible versions. As of SK 1.34.0, it works with Azure.AI.OpenAI 2.1.0 and Microsoft.Extensions.AI 10.3.0. Pin all three explicitly to avoid transitive version conflicts.

From GitHub Issue .NET 9 Microsoft.SemanticKernel 1.34.0 Azure.AI.OpenAI 2.1.0 Microsoft.Extensions.AI 10.3.0

By Rajesh Mishra · Feb 28, 2026 · Verified: Feb 28, 2026 · 8 min read

The Errors

NuGet dependency conflicts between AI packages produce several types of failures.

Build-time version conflict warning:

warning NU1603: Microsoft.SemanticKernel 1.34.0 depends on Azure.AI.OpenAI
(>= 2.0.0 && < 2.2.0) but Azure.AI.OpenAI 2.2.0 was resolved.

Runtime assembly binding failure:

System.IO.FileLoadException: Could not load file or assembly
'Azure.AI.OpenAI, Version=2.0.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'.
The located assembly's manifest definition does not match the assembly reference.

Runtime method not found (from mismatched versions):

System.MissingMethodException: Method not found:
'OpenAI.Chat.ChatCompletion Azure.AI.OpenAI.AzureOpenAIClient.CompleteChat(...)'.

The first is a warning that hints at future trouble. The second and third are hard failures that crash your application.

Why This Happens

The .NET AI ecosystem is a set of interconnected packages with tight version dependencies. Here is the typical dependency chain:

Microsoft.SemanticKernel 1.34.0
  └── Microsoft.SemanticKernel.Connectors.AzureOpenAI 1.34.0
        └── Azure.AI.OpenAI >= 2.0.0 && < 2.2.0
              └── OpenAI >= 2.1.0
              └── System.ClientModel >= 1.1.0

Microsoft.Extensions.AI 10.3.0
  └── Microsoft.Extensions.AI.Abstractions 10.3.0

Conflicts arise in three common scenarios.

Scenario 1: Direct + Transitive Version Mismatch

You add Azure.AI.OpenAI directly at version 2.2.0, but Semantic Kernel’s connector requires < 2.2.0. NuGet resolves the conflict using the highest requested version, but the Semantic Kernel code was compiled against the older API surface. Methods or types may have changed.

Scenario 2: Multiple Projects with Independent Versions

In a multi-project solution, Project A references Microsoft.SemanticKernel 1.34.0 and Project B references Azure.AI.OpenAI 2.2.0. When both are loaded at runtime, only one version of the Azure.AI.OpenAI assembly can exist in the AppDomain. Whichever version wins, the other project’s code may break.

Scenario 3: Microsoft.Extensions.AI Abstractions Mismatch

Both Semantic Kernel and Microsoft.Extensions.AI depend on the abstractions layer. If they expect different versions of Microsoft.Extensions.AI.Abstractions, interface implementations from one package may not satisfy type checks from the other.

Diagnosing the Conflict

Step 1: List All Package Versions

Run this from your solution or project directory:

dotnet list package --include-transitive

This shows both your direct references and everything pulled in transitively. Look for packages that appear multiple times at different versions — those are your conflicts.

For a specific focus on AI packages:

dotnet list package --include-transitive | findstr /i "OpenAI SemanticKernel Extensions.AI ClientModel"

Step 2: Check the Dependency Graph

For a deeper view of why a specific version was resolved:

dotnet nuget why Azure.AI.OpenAI

Or inspect the project.assets.json in the obj folder for the complete resolution graph. This file is generated during restore and contains every package and every version constraint.

Step 3: Check Semantic Kernel Release Notes

The Semantic Kernel team publishes which versions of Azure.AI.OpenAI are compatible with each release. Check the Semantic Kernel GitHub releases and the NuGet page for dependency metadata.

Fix 1: Align to a Compatible Version Set

The most reliable fix. Pin all AI packages to versions known to work together:

<!-- In your .csproj -->
<ItemGroup>
  <!-- Pin the trio to compatible versions -->
  <PackageReference Include="Microsoft.SemanticKernel" Version="1.34.0" />
  <PackageReference Include="Azure.AI.OpenAI" Version="2.1.0" />
  <PackageReference Include="Microsoft.Extensions.AI" Version="10.3.0" />
  <PackageReference Include="Microsoft.Extensions.AI.Abstractions" Version="10.3.0" />
</ItemGroup>

By adding explicit PackageReference entries for transitive packages, you override whatever version NuGet would resolve on its own. This gives you direct control.

Known Compatible Version Matrix

Semantic Kernel	Azure.AI.OpenAI	Microsoft.Extensions.AI	System.ClientModel
1.34.0	2.1.0	10.3.0	1.2.1
1.30.0	2.0.0	9.1.0	1.1.0
1.25.0	2.0.0-beta.6	9.0.0	1.0.0

Always verify against the actual release notes. These versions are accurate at the time of writing but the ecosystem moves quickly.

Fix 2: Adopt Central Package Management

For multi-project solutions, Central Package Management (CPM) is the structural fix. It ensures every project in the solution uses the exact same version of every package.

Create Directory.Packages.props at the solution root:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <!-- AI packages — upgrade these as a group -->
    <PackageVersion Include="Microsoft.SemanticKernel" Version="1.34.0" />
    <PackageVersion Include="Microsoft.SemanticKernel.Connectors.AzureOpenAI" Version="1.34.0" />
    <PackageVersion Include="Azure.AI.OpenAI" Version="2.1.0" />
    <PackageVersion Include="OpenAI" Version="2.1.0" />
    <PackageVersion Include="Microsoft.Extensions.AI" Version="10.3.0" />
    <PackageVersion Include="Microsoft.Extensions.AI.Abstractions" Version="10.3.0" />
    <PackageVersion Include="System.ClientModel" Version="1.2.1" />
  </ItemGroup>
</Project>

Then in each .csproj, reference packages without version numbers:

<ItemGroup>
  <PackageReference Include="Microsoft.SemanticKernel" />
  <PackageReference Include="Azure.AI.OpenAI" />
</ItemGroup>

The version comes from the central file. No project can accidentally drift to a different version.

For complete CPM documentation, see Central Package Management on Microsoft Learn.

Fix 3: Override Transitive Versions Explicitly

Sometimes you cannot change the top-level package version (it is pinned by another team, or the newer version has a bug). In that case, force a specific transitive version:

<ItemGroup>
  <PackageReference Include="Microsoft.SemanticKernel" Version="1.34.0" />

  <!-- Force a specific Azure.AI.OpenAI version even though SK
       would pull a different one transitively -->
  <PackageReference Include="Azure.AI.OpenAI" Version="2.1.0" />
</ItemGroup>

In CPM, use VersionOverride if a specific project needs something different from the central version:

<ItemGroup>
  <PackageReference Include="Azure.AI.OpenAI" VersionOverride="2.1.0" />
</ItemGroup>

Fix 4: Clean, Restore, and Rebuild

After changing any package versions, do a full clean rebuild. Stale binaries in the bin and obj folders can mask or create false conflicts:

dotnet clean
dotnet nuget locals all --clear
dotnet restore
dotnet build

Clearing NuGet locals ensures no cached package versions interfere with the fresh restore.

Verifying the Fix

After aligning versions, confirm there are no remaining conflicts:

# Check for NuGet warnings
dotnet build 2>&1 | findstr /i "NU1"

# Verify resolved versions
dotnet list package --include-transitive | findstr /i "OpenAI SemanticKernel Extensions.AI"

If no NU1xxx warnings appear and the resolved versions match your expectations, the conflict is resolved.

For runtime verification, add a startup check:

// Log actual assembly versions at startup
var skAssembly = typeof(Microsoft.SemanticKernel.Kernel).Assembly;
var aoaiAssembly = typeof(Azure.AI.OpenAI.AzureOpenAIClient).Assembly;

Console.WriteLine($"SemanticKernel: {skAssembly.GetName().Version}");
Console.WriteLine($"Azure.AI.OpenAI: {aoaiAssembly.GetName().Version}");

This catches cases where build succeeds but the wrong assembly is deployed.

Prevention Strategies

Treat AI packages as a version set. Never upgrade one without checking compatibility with the others. Create a comment block in your Directory.Packages.props listing which versions go together.
Test after every package update. Run integration tests that actually call Azure OpenAI, not just unit tests with mocks. Version conflicts often appear only at runtime.
Use dependabot or renovate grouping. Configure your dependency update tool to update Semantic Kernel, Azure.AI.OpenAI, and Extensions.AI in a single PR so they stay in sync.
Pin, do not float. Avoid version ranges like 2.* in production. Pin to exact versions for reproducible builds.
Monitor the Semantic Kernel release notes. Breaking changes in the connector layer are documented. Read them before upgrading.

⚠ Production Considerations

Version conflicts may only manifest at runtime, not build time. An assembly binding redirect that resolves during build can still throw FileLoadException or MissingMethodException when the wrong assembly version is loaded at runtime.
Upgrading Semantic Kernel without upgrading Azure.AI.OpenAI in lockstep frequently introduces breaking changes in the connector layer.

🧠 Architect’s Note

Treat the Semantic Kernel + Azure.AI.OpenAI + Extensions.AI trio as a single versioned unit. Upgrade them together, test together, and pin them together. Multi-project solutions should adopt Central Package Management from day one to prevent independent version drift.

AI-Friendly Summary

Summary

NuGet dependency conflicts between Semantic Kernel, Azure.AI.OpenAI, and Microsoft.Extensions.AI occur when transitive dependency versions diverge from directly referenced versions. Diagnose with 'dotnet list package --include-transitive'. Fix by aligning all packages to compatible versions, using explicit PackageReference entries to override transitive versions, and adopting Central Package Management (Directory.Packages.props) to enforce consistency across the solution.

Key Takeaways

Semantic Kernel pulls Azure.AI.OpenAI transitively — adding your own direct reference at a different version causes conflicts
Use 'dotnet list package --include-transitive' to diagnose version mismatches
Pin compatible version sets explicitly: SK 1.34.0 + Azure.AI.OpenAI 2.1.0 + Extensions.AI 10.3.0
Central Package Management (Directory.Packages.props) prevents version drift across multi-project solutions
Check SK release notes for the version compatibility matrix before upgrading any individual package

Implementation Checklist

Run dotnet list package --include-transitive to identify conflicting versions
Check Semantic Kernel release notes for the compatible version matrix
Add explicit PackageReference entries for transitive packages that conflict
Adopt Central Package Management with Directory.Packages.props
Clean and rebuild after version changes: dotnet clean && dotnet build
Run integration tests to verify runtime binding after version alignment

Frequently Asked Questions

Why do Semantic Kernel and Azure.AI.OpenAI versions conflict?

Semantic Kernel depends on a specific version range of Azure.AI.OpenAI as a transitive dependency. If you also reference Azure.AI.OpenAI directly at a different version, NuGet may not be able to resolve a single version that satisfies both constraints, causing build-time or runtime binding failures.

How do I find which NuGet packages conflict?