Repro Steps:
Expected Result:
Build succeed.
Actual Result:
Build failed with error:
C:Program Filesdotnetsdk3.1.400SdksMicrosoft.NET.Sdk.WindowsDesktoptargetsMicrosoft.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.' [C:Usersv-danchesourcerepos6p0TestTest.csproj]

Note:
It has been fixed on previous SDK 3.1.103-servicing-014950(runtime-3.1.3)
Dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 3.1.400
Commit: 035fb2aa2f
Runtime Environment:
OS Name: Windows
OS Version: 10.0.18362
OS Platform: Windows
RID: win10-x64
Base Path: C:Program Filesdotnetsdk3.1.400
Host (useful for support):
Version: 3.1.6
Commit: 3acd9b0cd1
.NET Core SDKs installed:
3.1.400 [C:Program Filesdotnetsdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.20 [C:Program FilesdotnetsharedMicrosoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.20 [C:Program FilesdotnetsharedMicrosoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.6 [C:Program FilesdotnetsharedMicrosoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.20 [C:Program FilesdotnetsharedMicrosoft.NETCore.App]
Microsoft.NETCore.App 3.1.6 [C:Program FilesdotnetsharedMicrosoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.6 [C:Program FilesdotnetsharedMicrosoft.WindowsDesktop.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Some more detail: This is a NET Framework 4.72 project that fails to build using .NET Core 3.1.4 targeting .NET Framework 4.72. .NET Core 3.1.302 targeting .NET Framework 4.72 builds fine.
This looks like a regression in PresentationBuildTasks. I'll follow-up when I have more information.
<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>
The ildiff shows a different version of MetadataLoadContext between the 3.1.302 and 3.1.4 PresentationBuildTask versions. Everything else looks similar
.assembly extern /23000012/ System.Reflection.MetadataLoadContext
{
.publickeytoken = (CC 7B 13 FF CD 2D DD 51 ) // .{...-.Q
.ver 4:0:1:1 <--
.ver 4:0:1:0
}
@ryalanms project.zip
Test project that reproduce the failure has been attached
https://github.com/dotnet/toolset/commit/067f54aa5c6996ed78b080b783375419f8d98034
<Sha>2dab42e151ea8020a75cdaaa8c46bf5d9093b8c0</Sha>
</Dependency>
<!-- For coherency purposes, this version should be gated by the version of wpf routed via core setup -->
<Dependency Name="Microsoft.NET.Sdk.WindowsDesktop" Version="3.1.3-servicing.20128.4" CoherentParentDependency="Microsoft.NETCore.App.Runtime.win-x64">
<Dependency Name="Microsoft.NET.Sdk.WindowsDesktop" Version="3.1.2-servicing.20066.4" CoherentParentDependency="Microsoft.NETCore.App.Runtime.win-x64">
<Uri>https://github.com/dotnet/wpf</Uri>
<Sha>b8c0f1ed4a1cd2cdd8dcbebc5ccff99993d4c3dd</Sha>
<Sha>589ace3c9fdfa0f1ea1640b82304a6a7ac597871</Sha>
</Dependency>
<Dependency Name="NuGet.Build.Tasks" Version="5.6.0-preview.2.6532">
<Uri>https://github.com/NuGet/NuGet.Client</Uri>
.NET 3.1.4 SDK contains the wrong version of Microsoft.NET.Sdk.WindowsDesktop: PresentationBuildTasks and MetadaLoadContext are several months old, and MetaloadContext is missing the support for the ‘retargetable’ AssemblyFlag, causing the build issue in the bug. (3.1.103 contains the correct version with newer binaries.)
This needs to be moved forward to the correct version. It looks like it is being synchronized manually.
@ryalanms it looks like the 3.1.4xx branch has been updated: https://github.com/dotnet/toolset/blob/release/3.1.4xx/eng/Version.Details.xml#L41. It was updated to the 3.1.6 runtime a few weeks ago: https://github.com/dotnet/toolset/pull/4685
/cc @wtgodbe @mmitche @dotnet/wpf-developers
Thanks, @sfoslund. Can you confirm that the correct version of the WindowsDesktop SDK is contained in the most recent version of 3.1.4xx?
The most recent public 3.1.xx version of the SDK installer available on the GitHub site still looks like it contains the old version of the WindowsDesktop SDK: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/3.1.4xx/dotnet-sdk-latest-win-x64.exe. (This is shown as 3.1.400-preview-015138.)
All builds from the last 2 weeks should have version 3.1.6-servicing.20315.3 but the SDK version 3.1.400-preview-015138 seems to be a pretty old build so I don't think it has this change. You can get more recent builds from the installer repo readme. Right now the most recent version there is 3.1.400-servicing-015221.
I have started hitting this issue on my WPF solution after updating to Visual Studio 16.7.0 (and whatever SDK comes along with it)
Many WPF users weren't able to migrate to 3.1 until around April because of this problem. Please consider moving the issue to dotnet/wpf since most users affected by this problem would be looking for it there. This scenario really needs regular regression testing as part of PBT testing. @rladuca Did you schedule any recurring manual tests for this scenario in the past?
@mmitche @ryalanms could this problem have been avoided in a repo-configuration that had a separate windowsdesktop repo to build WindowsDesktop runtime (instead of relying on core-setup) ?
So I see this - https://github.com/dotnet/toolset/pull/4489. Looks like the version was manually rolled back.
@rladuca noted to me offline that this scenario is being covered in end-to-end testing since mar. Several things could have happened - the test case could have passed and the problem could still have happened (i.e., inadequate test case), something could have fallen through the cracks in testing, the break could have been introduced after the test pass was completed etc., or something else. @ryalanms Rob will forward you an internal email thread re: this so you could follow up.
Visual Studio 16.7.1 and SDK 3.1.401 that were just released seem to have fixed the bug present with 3.1.400.
it has been fixed Visual Studio 16.7.1 and SDK 3.1.401.hence close it
Most helpful comment
Visual Studio 16.7.1 and SDK 3.1.401 that were just released seem to have fixed the bug present with 3.1.400.