microsoft / microsoft/foundry-local

Microsoft.AI.Foundry.Local.WinML 1.2.3 ships duplicate Microsoft.Windows.AI.MachineLearning.dll causing APPX1101 in packaged WinUI apps

Open
#849 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
2.6k
Forks
369
Avg merge
2d 17h
Merged PRs (30d)
39

Description

### Summary

`Microsoft.AI.Foundry.Local.WinML` **1.2.3** (via its transitive `Microsoft.AI.Foundry.Local.Core.WinML` 1.2.3) ships a **redundant private copy** of `Microsoft.Windows.AI.MachineLearning.dll` in its own `runtimes//native` folder, while *also* taking a package dependency on `Microsoft.Windows.AI.MachineLearning` 2.1.70 — the canonical package that already owns that DLL.

In an MSIX-packaged WinUI 3 app, both copies resolve to the same payload destination path and the build fails with **APPX1101: Payload contains two or more files with the same destination path**.

### Error

```
error APPX1101: Payload contains two or more files with the same destination path
'Microsoft.Windows.AI.MachineLearning.dll'. Source files:
...\microsoft.windows.ai.machinelearning\2.1.70\runtimes\win-arm64\native\Microsoft.Windows.AI.MachineLearning.dll
...\microsoft.ai.foundry.local.core.winml\1.2.3\runtimes\win-arm64\native\Microsoft.Windows.AI.MachineLearning.dll
```

(Same failure occurs for `win-x64`.)

### Minimal repro (stock template + one package)

```powershell
dotnet new winui -n WinMLDupeRepro
cd WinMLDupeRepro
dotnet add package Microsoft.AI.Foundry.Local.WinML --version 1.2.3
dotnet build -p:Platform=ARM64 -c Debug
```

The blank WinUI template references `Microsoft.WindowsAppSDK` 2.2.0, which transitively brings the canonical `Microsoft.Windows.AI.MachineLearning` 2.1.70. Adding the Foundry WinML package introduces the duplicate, and a plain packaged build fails. No extra configuration is needed.

### Dependency graph (`dotnet nuget why ... microsoft.windows.ai.machinelearning`)

```
'microsoft.windows.ai.machinelearning':
├── Microsoft.AI.Foundry.Local.WinML (v1.2.3)
│ └── Microsoft.AI.Foundry.Local.Core.WinML (v1.2.3)
│ └── Microsoft.Windows.AI.MachineLearning (v2.1.70)
└── Microsoft.WindowsAppSDK (v2.2.0)
└── Microsoft.WindowsAppSDK.ML (v2.1.70)
└── Microsoft.Windows.AI.MachineLearning (v2.1.70)
```

NuGet correctly unifies the canonical `Microsoft.Windows.AI.MachineLearning` package to a single 2.1.70. The collision is **not** a version conflict — it is the *extra, redundant* `Microsoft.Windows.AI.MachineLearning.dll` that `microsoft.ai.foundry.local.core.winml` 1.2.3 bundles itself:

```
microsoft.ai.foundry.local.core.winml\1.2.3\runtimes\win-arm64\native\Microsoft.Windows.AI.MachineLearning.dll
microsoft.ai.foundry.local.core.winml\1.2.3\runtimes\win-x64\native\Microsoft.Windows.AI.MachineLearning.dll
```

### Expected

`Microsoft.AI.Foundry.Local.Core.WinML` should not re-ship `Microsoft.Windows.AI.MachineLearning.dll` (or any other binary already owned by the `Microsoft.Windows.AI.MachineLearning` / `Microsoft.WindowsAppSDK.ML` package it depends on). It should consume that DLL from the canonical package so there is exactly one copy in the MSIX payload.

### Actual

Two copies of `Microsoft.Windows.AI.MachineLearning.dll` are placed at the same payload path → APPX1101 → packaged build fails.

### Workaround

Strip the Foundry copy from the payload via an MSBuild target:

```xml





```

(The same package also redundantly ships `onnxruntime.dll`, which needs an equivalent dedupe — likely the same root cause.)

### Environment

- `Microsoft.AI.Foundry.Local.WinML` 1.2.3 / `Microsoft.AI.Foundry.Local.Core.WinML` 1.2.3
- `Microsoft.WindowsAppSDK` 2.2.0 / `Microsoft.WindowsAppSDK.ML` 2.1.70 / `Microsoft.Windows.AI.MachineLearning` 2.1.70
- `Microsoft.Windows.SDK.BuildTools.MSIX` 1.7.251221100
- .NET 10, `net10.0-windows10.0.26100.0`, WinUI 3 single-project MSIX
- RIDs affected: `win-arm64`, `win-x64`

Contributor guide

Open the contributing guide

Research direction

Inspect the runtimes/win-arm64/native and runtimes/win-x64/native contents of microsoft.ai.foundry.local.core.winml 1.2.3, then reproduce the collision with the WinUI template and the stated dotnet build command. Compare the bundled files with Microsoft.Windows.AI.MachineLearning and Microsoft.WindowsAppSDK.ML; done means packaged builds complete without APPX1101 and no duplicate native payloads remain.

Written by the indexing model from the issue text.

Assessment

Domain
build-system, desktop-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.