wpf: Microsoft.WinFX.targets Unknown build error Could not find assembly 'mscorlib'

  • .NET Core Version: happens both with 3.1.401 and 5.0.100-preview.8.20417.9
  • Windows version: Win 10 (1909) 10.0.18363
  • Does the bug reproduce also in WPF for .NET Framework 4.8?: for TFMs netcoreapp3.1 and net50
  • Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc…)? No, Visual Studio is not involved, only dotnet build from command line

This is essentially a duplicate of the closed https://github.com/dotnet/wpf/issues/3183 ; the ticket was closed, although it was not resolved and I cannot re-open it. @ryalanms told me to reactivate when I see the issue again. Well, it has never been resolved for me. Sorry for the double-issue.

Problem description: WPF core app doesn’t build when adding a direct <Reference …/> to an old .Net 2.0 WinCE-compatible framework dll. (Why would you do that? Expensive, proprietary dll from 3rd party, we can’t live without it, author has retired)

Actual behavior: dotnet build fails with either (SDK 3.1.401)

C:\Program Files\dotnet\sdk\3.1.401\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(225,9): 
error MC1000: Unknown build error, 'Could not find assembly 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=969db8053d3322ac'. 
Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly.'

or (SDK 5.0.100-preview.8.20417.9)

C:\Program Files\dotnet\sdk\5.0.100-preview.8.20417.9\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(240,9):
error MC1000: Unknown build error, 'Could not find assembly 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=969db8053d3322ac'. 
Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly.'

Expected behavior: dotnet build runs fine.

Minimal repro:

  • dotnet new wpf
  • TFM either netcoreapp3.1 or net50
  • Add a library reference to an old .Net Framework 2.0 WinCE library like so: <Reference Include="SomethingOld" HintPath="SomethingOld.dll" />
  • dotnet build Unfortunately I can’t publish the proprietary dll here. It is built for .Net Framework 2 with WinCE compatibility.

@ryalanms said that is should be fixed in 3.1.401, but it is not fixed. He mentioned another version number 16.7.1 - unclear what for. Visual Studio is not involved and I’ve tested with different MSBuild versions too (the 5.0 preview comes with msbuild 16.8.0.xxx).

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Comments: 33 (13 by maintainers)

Most upvoted comments

This should have been fixed with https://github.com/dotnet/corefx/pull/42768. I am able to reproduce the failure with @jw-suh’s test project.

/cc @dotnet/wpf-developers

@singhashish-wpf the workarounds stated above don’t actually work, as the people who tried them also stated above. We managed to make it work by adding a dependency to System.Runtime.CompilerServices.Unsafe and using msbuild instead of dotnet to build our our solutions.

One other good piece of data to gather here: does the compiler permit it? If CSC is also ignoring publicKey it may be fair to ask SRM to relax the constraint. What happens in a normal net5 project where you build against this assembly and try to interact with its API that references types that would live in mscorlib?

The assembly reference in the metadata must include ‘retargetable’ or there is no way for the resolver to know that it has permission to use a newer version of that assembly:

// Metadata version: v4.0.30319 .assembly extern retargetable mscorlib { .publickeytoken = (7C EC 85 D7 BE A7 79 8E ) // |…y. .ver 2:0:5:0 }

Here is the manifest for the dll used in the repro project. Note that it is missing retargetable.

// Metadata version: v2.0.50727 .module extern MdpApi.dll .assembly extern mscorlib { .publickeytoken = (96 9D B8 05 3D 33 22 AC ) // …=3". .ver 2:0:0:0 }

Thanks @jw-suh for the explanation… stupid me 😃 It works with my sample, because the WinCE objects are not used in the UI.

Here’s a workaround that you can add to your csproj that you could use until it is fixed:

  <Target Name="RemoveMdpNetApi" BeforeTargets="MarkupCompilePass1">
    <ItemGroup>
      <_TempWPFReference Include="@(ReferencePath)" />
      <ReferencePath Remove="@(ReferencePath)" Condition="'%(ReferencePath.Filename)'=='MdpNetApi'" />
    </ItemGroup>
  </Target>
  
  <Target Name="RestoreMdpNetApi" AfterTargets="MarkupCompilePass2">
    <ItemGroup>
      <ReferencePath Remove="@(ReferencePath)" />
      <ReferencePath Include="@(_TempWPFReference)" />
    </ItemGroup>
  </Target>

This basically removes the .Net Framework 2.0 CE from being loaded in the markup compilation. The only thing is that you cannot use anything from your .Net Framework 2.0 CE dll inside your xaml.

6.0.100-preview.6.21355.2 does not fix it, just tested it.

Since I have run into the same problem, I want to add the little information I have not yet found in the issues.

The Problem does not occur by creating a WPF Project. A completely empty WPF project will compile. As soon as you add any Page, Window etc. the project breaks.

Find attached an empty WPF library and a WPF library with a Page: EmptyWpfApp.zip NonEmptyWpfApp.zip

I hope this information helps at least narrowing down the error cause.

This issue is blocking all potential migration work, there is no workaround up to now, and we are stuck on net 4.8 framework. I understand that developer resources are limited (very limited for WPF especially), but there has been no progress for several month! It would be nice to get some feedback on this at least (can you reproduce it, workaround ideas, milestone expectation).