wpf: Updating to 16.4 from 16.3.x causes build issues with WPF project file.

There is a fix queued for this in the next update (3.1.3) which should be available shortly.

I also want to offer some context on the delay, which is a failure on our end. The problem and the solution turned out to be a bit nuanced and hard to track down.

We did fix this in 3.1.2 as part of https://github.com/dotnet/corefx/pull/42768 or so we thought.

To understand what really happened, you have to understand how a .NET Core SDK is put together, where the fix had to be made, and how the fix makes its way from point-of-fix to point-of-consumption.

The point of fix-consumption

The WindowsDesktop SDK, the one that is referred to in WPF and WinForms projects by the line <Project SDK="Microsoft.NET.Sdk.WindowsDesktop">, is a set of build tools, properties and targets. Typically, it can be found under $env:ProgramFiles\dotnet\sdk\3.1.102\Sdks\Microsoft.NET.Sdk.WindowsDesktop or a similar path.

The fix was needed in System.Reflection.MetadataLoadContext.dll carried by the tools bundled with this SDK.

    DOTNET\SDK\3.1.102\SDKS\MICROSOFT.NET.SDK.WINDOWSDESKTOP\TOOLS\NET472
        |   PresentationBuildTasks.dll
        |   System.Collections.Immutable.dll
        |   System.Memory.dll
        |   System.Numerics.Vectors.dll
        |   System.Reflection.Metadata.dll
        |   System.Reflection.MetadataLoadContext.dll     <------- Needs a Fix
        |   System.Runtime.CompilerServices.Unsafe.dll

Aside: These DLL’s exist to support PresentationBuildTasks.dll, which is a set of MSBuild Tasks used to support Markup Compilation. The copy of these common DLLs have to be bundled with it to ensure that the assembly can be loaded reliably within MSBuild.

Where is the fix made?

System.Reflection.MetadataLoadContext.dll is a core library built out of dotnet/corefx (which has since been migrated to dotnet/runtime in .NET 5). It was fixed as part of https://github.com/dotnet/corefx/pull/42768

How do fixes ‘move’ from one repository to another in the .NET Core build process?

To explain this, I want to share a snapshot of how various repositories are interconnected.

dotnet/wpf consumes updates from dotnet/corefx by propagating version updates via dotnet/core-setup -> dotnet/winforms.

It can be observed in the flow-diagram above that dotnet/wpf also propagates its own version updates into dotnet/core-setup (through dotnet-wpf-int).

This sets up a perpetual cycle of builds, like this:

-> dotnet\wpf -> dotnet-wpf-int -> dotnet/core-setup -> dotnet/winforms -> dotnet/wpf ->

This perpetual cycle was not a serious problem during active product development of .NET Core 3.0/3.1 - we create a lot of builds, builds take a lot of time to complete, and the overall progress tends to be relatively slow.

But once the product stabilized and switched to servicing, this perpetual-build engine couldn’t be allowed to continue. To break this cycle, the edge from dotnet/core-setup -> dotnet/winforms had been disabled (which can also been seen in the flow-diagram).

We have only created a handful of servicing builds since .NET Core 3.1 was announced (we are just about to release 3.1.3), and we didn’t take this change into account. More importantly, we failed to grasp the implications for Microsoft.NET.Sdk.WindowsDesktop and put one and one together.

What this change (the disablement of the edge from dotnet/core-setup -> dotnet/winforms) meant was that updates from dotnet/corefx wouldn’t flow seamlessly into dotnet/wpf.

Aside: This has already been improved/remedied in master/.NET 5 repos. With the introduction of dotnet/windowsdesktop as a separate place to build Microsoft.WindowsDesktop.App, WinForms and WPF repos no longer have a need to flow their versions into dotnet/core-setup (which has since been superseded by dotnet/runtime) directly. This eliminates the cycle in the build process.

What happened ?

The above flow process works fine for the vast majority of scenarios. The all-up product construction (Mirosoft.WindowsDesktop.App shared framework) happens in dotnet/core-setup, where the right bits are usually integrated together. dotnet/wpf (or dotnet/winforms) not receiving the latest versions from dotnet/corefx simply means that these repos build against slightly older reference assemblies - except in the case of Microsoft.NET.Sdk.WindowsDesktop construction. In the latter case, dotnet/wpf is where the “product” is assembled, and when it needed the latest runtime binaries, it only had access to a slightly older version that lacked the right fixes.

• During the construction of .NET Core 3.1.2, the fix was built successfully out of dotnet/corefx, but never made its way back to dotnet/wpf
• We failed to catch it in testing WPF
  • We had handed over the issue to dotnet/corefx as a runtime bug, and failed to add a test-case for validation. Our private validations seems to pass since we were working with, well, privates.

By the time we understood the full scope of what happened and how, 3.1.3 was almost ready and it was looking like the fix may not make it into the schedule. We decided to delay 3.1.3 a bit and rebuild it to take the fix into it anyway. Ultimately, this was all that was needed - https://github.com/dotnet/wpf/pull/2670 (well, followed by an across-the-board rebuild, resetting the progress we had made in 3.1.3 so far across the board, retesting, etc.).

/cc @rladuca

I can confirm this has been fixed in 3.1.103, great work, thanks!

Still have the same issue on 3.1.2 😦

[build-up, build]: C:\Program Files\dotnet\sdk\3.1.102\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(225,9): error MC1000: Неизвестная ошибка сборки, "Could not find assembly 'mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly."

Same issue here, still, with 3.1.2.

Please try to fix this asap because it seems this is a showstopper for many of use.

I was eagerly waiting for this fix, but it’s not working?

I have this defined in global.json:

{
	"msbuild-sdks": {
		"MSBuild.Sdk.Extras": "2.0.54"
	},
	"sdk": {
		"version": "3.1.102"
	}
}

Still getting this error:

3>------ Rebuild All started: Project: MyProject, Configuration: Debug Any CPU ------
3>Build started 18-2-2020 22:09:50.
3>Target _ComputeTargetFrameworkItems:
3>Target Clean:
3>  Target CoreClean:
3>    Deleting file "C:\Source\MyProject\src\MyProject\obj\Debug\net462\MyProject.csprojAssemblyReference.cache".
3>    Deleting file "C:\Source\MyProject\src\MyProject\obj\Debug\net462\MyProject.exe.config".
3>  Target _GetProjectReferenceTargetFrameworkProperties:
3>Target DispatchToInnerBuilds:
3>  Target ResolveProjectReferences:
3>  Target _WriteAppConfigWithSupportedRuntime:
3>    Skipping target "_WriteAppConfigWithSupportedRuntime" because all output files are up-to-date with respect to the input files.
3>  Target MarkupCompilePass1:
3>    C:\Program Files\dotnet\sdk\3.1.102\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(225,9): error MC1000: Unknown build error, 'Could not find assembly 'mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly.'
3>  Done building target "MarkupCompilePass1" in project "MyProject.csproj" -- FAILED.
3>
3>  Done building project "MyProject.csproj" -- FAILED.
3>
3>Build FAILED.

Note that this happens to some projects, not all of them. I am still trying to figure out when exactly this is happening.

.NET Core 3.1.3 Release Notes

Download .NET Core 3.1

Are there any news on this? 3.1.2 didn’t fix it, is using 3.0.101 with global.json the only workaround? Isn’t 3+ months quite a long time to have a severe bug like this go unfixed?

Installing the 3.0.101 SDK and using global.json to force it, is a viable workaround that does not require rolling back all of VS, while we look at the issue and work on fixing it.

But this is hopefully not the solution we have to accept…

Still have the same issue on 3.1.2 😦

[build-up, build]: C:\Program Files\dotnet\sdk\3.1.102\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(225,9): error MC1000: Неизвестная ошибка сборки, "Could not find assembly 'mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly." [D:\Projects\Work\Git\Sungero\Common\src\Controls\Controls.csproj]

This fix is in 3.1.2 which is scheduled to release 2/18. Obviously things can happen between here and there to impact the final date but, that’s the target.

What is the state of this issue: Can we expect a VS update which solves this or what is the plan? Thanks for more info.

https://github.com/dotnet/corefx/pull/42768 fixes this, which is targeted for 3.1.2 milestone.

We release updates at approx. 1-2 month cadence (.NET Core Roadmap]).

Note that the last update (3.1.1) was released on Jan 14, 2020, and we hope to release this fix in the following update to .NET Core 3.1 (unless, of course, something unexpected results in a change of plans).

From my experience, that’s because you are using the new “SDK-style” projects, which by definition use the .NET Core SDK/build system. When using the old “.NET Framework” project files, it will work fine.

That makes sense, Siegfried! I am indeed using the new style projects…

Me as well. But I will NEVER go back to the old csproj style : )

I had the same problem too. I fixed it, as mentioned above, by installing the .NET Core 3.0.101 SDK and adding a global.json file. However, why do I have to install a .NET Core SDK if my project isn’t targetting .NET core at all?

See the attached project.

I could reproduce it with an almost plain WPF project and a reference to Unit v4.0.1. I know, this is a very old version but for legacy reason I have to stick to this version. Before the VS 16.4 update it was no problem to build the project with this reference.

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
    <RootNamespace>Test</RootNamespace>
    <AssemblyName>Test</AssemblyName>
    <OutputType>WinExe</OutputType>
    <UseWPF>true</UseWPF>
    <FileVersion>0.0.0.9999</FileVersion>
    <AssemblyVersion>0.0.0.9999</AssemblyVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Unity" Version="4.0.1" />
  </ItemGroup>

</Project>

project.zip

@ericstj please update us on this issue, the new sdk still has the same problem and the workaround suggested also not working

Oh Damn, Such a frustrating moment, didn’t expect such a scenario from Microsoft Development Platform… Please try to fix this issue and release asap

https://github.com/dotnet/wpf/issues/2274#issuecomment-590783681

this workaround is not correct. the issue still exist in the all of .net core sdks

My VB WPF control libraries have the same problem.

Minimal log

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

The log of failed build task

1>    Microsoft (R) Build Task 'MarkupCompilePass1' Version '4.800.119.60507'.
1>    Copyright (C) Microsoft Corporation 2005. All rights reserved.
1>
1>    Current project directory is 'D:\WPF_Borderless_Window\TempCompileLib\'.
1>    Analysis Result : 'All'.
1>    Recompiled XAML file : 'D:\WPF_Borderless_Window\TempCompileLib\Themes\Generic.xaml'.
1>    Recompiled XAML file : 'D:\WPF_Borderless_Window\TempCompileLib\UserControl1.xaml'.
1>    Started the markup compilation.
1>    OutputType is 'library'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\PresentationCore.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\PresentationFramework.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Core.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Data.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Drawing.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.IO.Compression.FileSystem.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Numerics.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Runtime.Serialization.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Windows.Controls.Ribbon.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Xaml.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Xml.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Xml.Linq.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\UIAutomationClient.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\UIAutomationClientsideProviders.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\UIAutomationProvider.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\UIAutomationTypes.dll'.
1>    Input: Assembly Reference file: 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\WindowsBase.dll'.
1>    C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(225,9): error MC1000: Unknown build error, 'Could not find assembly 'mscorlib, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly.'
1>    Output Property: _RequireMCPass2ForMainAssembly=False
1>    Output Property: _RequireMCPass2ForSatelliteAssemblyOnly=False
1>    Output Item(s): FileWrites=
1>  Done executing task "MarkupCompilePass1" -- FAILED.
1>Done building target "MarkupCompilePass1" in project "TempCompileLib.vbproj" -- FAILED.

I solved this issue by adding reference to “mscorlib” in my project.

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
    <RootNamespace>CompileNetFxWpfWithNetCore31Sdk</RootNamespace>
    <TargetFrameworks>netcoreapp3.1;net461</TargetFrameworks>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="mscorlib" Condition="'$(TargetFramework)' == 'net461'"/>
  </ItemGroup>
</Project>

We were going to update our open source project to use 2019 & .NET Core 3.0 but because of this issue, this is blocking us from proceeding forward with the upgrade.

The workaround of installing older SDK and using global.json is no-go for us because while that would have worked for AppVeyor (our build server), it would not be something we can have our contributor manually download & install as I understand that the specific SDK version cannot be downloaded & installed as part of the Visual Studio build. This is quite unfortunate.

I have a WPF project targeting net451 and net472 but using the Microsoft.NET.Sdk.WindowsDesktop SDK using the new csproj format. In VS 16.3.9 it was working, after upgrading to 16.4.1 I have the same issue. Could not find System.Core 2.0.5.0

I have all the targeting pack installed.

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFrameworks>net451;net472</TargetFrameworks>
    <LangVersion>latest</LangVersion>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

If I remove net451 everything works. I can build for 472 successfully, Did you raise the minimum framework version or something? We have both because we always build two versions for customers who don’t have an up-to-date framework on their computers.

Yes, beginning with VS 16.3, VS will only “root” the one SDK it comes with. If VS installed an SDK and you upgrade to a VS that brings a newer SDK, it will remove the older SDK and add the newer one. There is ref counting so that if you install an SDK standalone, it will never be uninstalled by VS. VS gets one ref count and the standalone install gets another. If you have scenarios where you need multiple SDKs, you have to install the other ones standalone.

This came after a TON of feedback against leaving SDKs behind from VS upgrades.

I am advocating that the global.json default policy should allow roll forward to any newer version by default. You now have control over the roll forward, but the default is very restrictive and will only roll across the xx in A.B.Cxx if the matching version is not found.

cc @KathleenDollard

<TargetFramework>net461</TargetFramework> <TargetFramework>net472</TargetFramework>

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

Microsoft.WinFX.targets(225,9) is MarkupCompilePass1; When building a project for TargetFrameowrk=net472, it usually resolves mscorlib to a path like this:

Input: Assembly Reference file: ‘C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2\mscorlib.dll’.

@olivegamestudio, @zplan, are you sure that .NET 4.6.1 and .NET 4.7.2 targeting packs are installed for you respectively?

Same issue here

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"> <PropertyGroup> <TargetFramework>net472</TargetFramework> <UseWPF>true</UseWPF> <FileVersion>0.0.0.9999</FileVersion> <AssemblyVersion>0.0.0.9999</AssemblyVersion> </PropertyGroup>

Workaround: Because only sdk 3.1.100 is installed after the update, I installed “dotnet-sdk-3.0.101-win-x64” and added a global.json with 3.0.101 to the project root. Now at least it compiles again (but with 3.0)

Using Visual Studio 16.6, migrating WPF app to target .netcore3.1(.300). Cannot compile with error below:

Error MC1000 Unknown build error, ‘Could not find assembly ‘System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly.’ MyApp C:\Program Files\dotnet\sdk\3.1.300\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets 225

Is this the same issue? I seem to have most current .netcore (3.1.300) and VS16.6.0.

Any suggestions how to get compiled?

Can you shed some light on the ETA or is it too early to tell?

@GeertvanHorrik as things stand, we are hoping for for 24/03/2020 (assuming that factors outside our control do not change this plan, of course 😄).

Are there any news on this? 3.1.2 didn’t fix it, is using 3.0.101 with global.json the only workaround? Isn’t 3+ months quite a long time to have a severe bug like this go unfixed?

We already moved to python for development platform, Microsoft really keeps on disappointing as a development platform, python is amazing in fixing bugs ASAP

This has us blocked from updating to the WindowsDesktop sdk project format.

@vatsan-madhavan I got the same issue When I migrate my WPF app from .NET Framework 4.6 to .NET Core 3.1, is there any workaround found or do we have to wait till the next release? (I am using VS 16.5)

@vatsan-madhavan : I did this already long time ago. see my comment on Dec 6, 2019

@zplan, @elparasite, can you share a repro project that shows your error ?

Something small/self-contained that picks out the essential characteristics of the project that is affected by this bug would be nice. Chances are good that the NuGet references are the key.

/cc @rladuca, @nguerrera

Did some more investigation, I think this is the culprit (System.ValueTuple):

@pieterphilippaerts

However, why do I have to install a .NET Core SDK if my project isn’t targetting .NET core at all?

From my experience, that’s because you are using the new “SDK-style” projects, which by definition use the .NET Core SDK/build system. When using the old “.NET Framework” project files, it will work fine.

It would be very helpful if someone who is hitting this could provide a binlog with the failure.