wpf: Could not find assembly 'System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
- .NET Core Version: (e.g. 3.0 Preview1, or daily build number, use
dotnet --info) - Windows version: (
17763.379) - Does the bug reproduce also in WPF for .NET Framework 4.8?: I haven’t tried
Problem description: Using the latest core-sdk version, the WPF app from the https://github.com/ridomin/msix-catalog repo no longer builds.
Actual behavior:
Microsoft.WinFX.targets(243,9): error MC1000: Unknown build error, 'Could not find assembly 'System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly.' [D:\GIT\msix-catalog-master\msix.catalog.app\msix.catalog.app.core.csproj]
Expected behavior: Compilation should work.
Minimal repro:
- Download https://github.com/ridomin/msix-catalog
- cd msix-catalog-master\msix.catalog.app
- dotnet publish -r win-x64 msix.catalog.app.core.csproj
NOTE:
I’m observing that we’re now setting _PresentationBuildTaskTfm to netcoreapp2.1 in Microsoft.WinFX.targets:
<_PresentationBuildTasksTfm Condition="'$(MSBuildRuntimeType)' == 'Core'">netcoreapp2.1</_PresentationBuildTasksTfm>
It used to be netcoreapp3.0. Is this intentional?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (6 by maintainers)
Commits related to this issue
- Public key tokens of .NET core WPF assemblies and .NET Framework WPF assemblies need to match (#515) This is the public half of a two part change. The original fix (adding StrongNameKeyId=Ecma to WPF... — committed to dotnet/wpf by ryalanms 5 years ago
- Preview 5 Branch Snap (#617) * Update dependencies from https://github.com/dotnet/arcade build 20190207.1 (#332) This change updates the following dependencies - Microsoft.DotNet.Arcade.Sdk - 1.0... — committed to dotnet/wpf by vatsan-madhavan 5 years ago
@vatsan-madhavan provided a more comprehensive fix that I am still testing locally. Thanks.
The propsed fix is good. Everything builds cleanly when all reference assemblies are built against a new System.Xaml that contains the desktop public key token. I’m currently working with @vatsan-madhavan to set StrongNameKeyId to ECMA for all shipping WPF assemblies. Thank you @fadimounir for reporting the issue and @nguerrera for root-causing.