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
- 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
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