Wpf: Could not find assembly 'System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

[fadimounir]

• .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:
1) Download https://github.com/ridomin/msix-catalog
2) cd msix-catalog-master\msix.catalog.app
3) 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?

[fadimounir]

Here's my .NET Core Version info:

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview4-011077
 Commit:    c32af26f6f

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x86
 Base Path:   D:\GIT\sdk\.dotnet\sdk\3.0.100-preview4-011077\

Host (useful for support):
  Version: 3.0.0-preview4-27605-02
  Commit:  70d56fffb1

.NET Core SDKs installed:
  3.0.100-preview4-011077 [D:\GIT\sdk\.dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0-preview4-19204-04 [D:\GIT\sdk\.dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.5 [D:\GIT\sdk\.dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [D:\GIT\sdk\.dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [D:\GIT\sdk\.dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.3 [D:\GIT\sdk\.dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview4-27605-02 [D:\GIT\sdk\.dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview4-27604-2 [D:\GIT\sdk\.dotnet\shared\Microsoft.WindowsDesktop.App]

[fadimounir]

The System.Xaml.dll assembly that gets passed to the MarkupCompilePass1 task is coming from:
D:\GIT\sdk\.dotnet\shared\Microsoft.WindowsDesktop.App\3.0.0-preview4-27604-2\System.Xaml.dll
And has the following identity:
System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

The public key token here is different than the one the task was trying to load, which is why it's throwing the exception.

[nguerrera]

@vatsan-madhavan @ryalanms

[nguerrera]

The System.Xaml.dll assembly that gets passed to the MarkupCompilePass1 task is coming from:
D:\GIT\sdk.dotnet\shared\Microsoft.WindowsDesktop.App\3.0.0-preview4-27604-2\System.Xaml.dll

What? We should not be passing paths from the shared framework into the build task.

[nguerrera]

I can repro this, but it looks like only C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\3.0.0-preview4-27605-09\ref\netcoreapp3.0\System.Xaml.dll is passed into the task (which is correct).

Seems like something else in the references is referencing System.Xaml with a different PKT. There should only be one PKT for System.Xaml, though and it should be the same as the one from desktop. cc @ericstj

[ryalanms]

I'm trying to repro now...

[nguerrera]

Looks like https://github.com/dotnet/wpf/issues/208

My guess is that removing the hack that was probing beside things by simple name and just using PathAssemblyResolver directly caused this, but true root cause is that there are System.Xamls with a bogus PKT and the hack that was removed was masking it.

[ryalanms]

Thanks for root-causing this @nguerrera . I've confirmed the public key token of System.Xaml assemblies does not match the desktop public key token and am testing the fix recommended in issue #208.

[ryalanms]

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.

[nguerrera]

set StrongNameKeyId to ECMA for all shipping WPF assemblies

Goes without saying but make sure they were all ECMA on desktop. Desktop framework has a mix of different keys.

[nguerrera]

Yeah, some were not ECMA:

λ sn -T "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\PresentationCore.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key token is 31bf3856ad364e35

[ryalanms]

@vatsan-madhavan provided a more comprehensive fix that I am still testing locally. Thanks.

[ryalanms]

@fadimounir: The fix went in on Saturday 4/7. Could you verify and close? Thanks.

[fadimounir]

@ryalanms Thanks for pushing the fix. I tested it on my end and it worked. Closing

[ryalanms]

Thanks.