Updating to 16.4 from 16.3.x causes build issues with WPF project file. #2274

olivegamestudio · 2019-12-04T10:00:36Z

When building a WPF project the following error is shown, this built fine in the last 16.3.x version that was released.

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.'

The project file:

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

  <PropertyGroup>
    <OutputType>Library</OutputType>
    <TargetFramework>net461</TargetFramework>
    <UseWPF>true</UseWPF>
    <Platforms>x86</Platforms>
    <GeneratePackageOnBuild>false</GeneratePackageOnBuild>
    <Version>1.0.0</Version>
    <Description></Description>
    <FileVersion>1.0.0.0</FileVersion>
    <AssemblyVersion>1.0.0.0</AssemblyVersion>
    <ApplicationIcon />
    <StartupObject />
  </PropertyGroup>

</Project>

The text was updated successfully, but these errors were encountered:

zplan · 2019-12-04T11:44:14Z

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)

olivegamestudio · 2019-12-04T16:09:51Z

Yes i added the following global.json alongside my solution:

{
    "sdk": {
      "version": "3.0.100"
    }
  }

zplan · 2019-12-04T18:56:37Z

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

vatsan-madhavan · 2019-12-04T19:27:15Z

<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?

vatsan-madhavan · 2019-12-04T19:28:21Z

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

@livarcocc, @nguerrera, @chabiss, is it expected that 3.0.100 or 3.0.101 SDK vanishes when upgrading from Dev16.3.x --> Dev16.4?

olivegamestudio · 2019-12-04T19:29:32Z

Yes double-checked. When I change my target to 471 it compiles okay. Seems that the latest update has made that the minimum .NET version? Unfortunately, I can't target 471 and need 461. But this all worked under the last 16.3 update, it's only broke since updating to 16.4.

nguerrera · 2019-12-04T19:44:11Z

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

njannink · 2019-12-04T19:56:08Z

Im having the same issue. This is currently blocking my work. I checked VS Installer and I have all required targetting packs and NetCore SDK 3.1

What is the proposed solution / workaround or is it possible to rollback a Visual Studio update?

nguerrera · 2019-12-04T19:58:42Z

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.

nguerrera · 2019-12-05T18:49:28Z

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

zplan · 2019-12-06T07:55:21Z

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

pieterphilippaerts · 2019-12-06T15:51:54Z

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?

siegfriedpammer · 2019-12-13T08:12:18Z

@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.

pieterphilippaerts · 2019-12-13T08:23:20Z

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...

zplan · 2019-12-13T09:43:32Z

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 : )

Dunge · 2019-12-16T17:13:11Z

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.

ds1709 · 2019-12-19T15:50:44Z

I have net40 WPF project with Microsoft.Bcl.Async (important, refers on mscorlib 2.0.5.0). Builds successfully in VS 16.3, but fails in 16.4.

bclothier · 2019-12-22T19:49:35Z

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.

zplan · 2020-01-17T12:46:52Z

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.

Nukepayload2 · 2020-01-22T02:08:20Z

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>

vatsan-madhavan · 2020-01-22T19:03:34Z

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.

dotnet/corefx#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).

Nukepayload2 · 2020-01-23T01:41:14Z

@vatsan-madhavan
Does dotnet/corefx#42768 apply to VB projects? It fixes dotnet/runtime#730 , and dotnet/runtime#730 was fixed in .NET 5 dotnet/corefx#40581 . But this problem is reproducible when building VB WPF projects with .NET Core SDK 5.0.100-alpha.1.20064.2.

jogibear9988 · 2020-01-29T20:49:55Z

@vatsan-madhavan maybe it is possible to release this earlier? or is there a preview version?

vatsan-madhavan · 2020-01-30T00:48:41Z

@leecow Can we share a better timeline for when we'll ship dotnet/corefx#42768?

GeertvanHorrik · 2020-03-07T07:41:43Z

@ds1709 as started before, you should use 3.0.101 until this is fixed in 3.1.x:

{ "sdk": { "version": "3.0.101" } }

ds1709 · 2020-03-07T08:17:25Z

@ds1709 as started before, you should use 3.0.101 until this is fixed in 3.1.x:

{ "sdk": { "version": "3.0.101" } }

I'm building WinForms application with WPF ElementHost. And after creating global.json i got another error

Unknown build error, 'Could not load type 'System.Drawing.BitmapSuffixInSatelliteAssemblyAttribute' from assembly 'System.Drawing, Version=4.0.0.0 ...

MichaeIDietrich · 2020-03-07T15:00:37Z

As long as we are limited to 3.0 as sdk version, we are not able to use .NET Core 3.1 as target framework for applications (e.g. for having mixed mode assembly support).

Is this the case or do I get something wrong?

ds1709 · 2020-03-08T17:05:09Z

Ok, after some research I found, what problem is in PresentationBuildTasks.dll assembly. I desided to debug it to find the problem. Clonned repository, build it and... It works without any problem. So, my question is: what's the point to hold the fix, why can't you just release it?
Assumes, I should use this localy builden assembly for a while.

kopfsick · 2020-03-16T14:22:42Z

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?

nirzaf · 2020-03-16T16:33:15Z

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

zmj · 2020-03-19T02:49:52Z

+1 for not working on 3.1.2

czdietrich · 2020-03-19T11:51:02Z

Please give us some information here. We are completely stuck and cannot move from .NET Framework to .NET Core, since we need .NET Core 3.1 features to make this transition.
.NET Core 3.1.200 still produces the same error and .NET Core 3.0 is out of support and prevents us from using .NET Core 3.1 features.

What is the plan behind? We do not get any feedback.
Shall we wait for .NET 5? (in fact latest .NET 5 preview fixed this issue for us)

AdamVasPrezi · 2020-03-19T16:25:20Z

I want to join to the others. Please move on! At least give us a little piece of information... Is it ongoing? Won't be fixed?
3.1 is LTS :/ (?)

vatsan-madhavan · 2020-03-19T22:13:59Z

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 dotnet/corefx#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 dotnet/corefx#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 - #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

GeertvanHorrik · 2020-03-20T08:38:59Z

Fantastic response @vatsan-madhavan , thanks for this honest evaluation / retrospective. We are looking forward to this 3.1.3 release and will provide feedback immediately once it has been released (but now have full confidence it's fixed!).

we are just about to release 3.1.3

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

Again, thanks for the response and hopefully this ticket can be closed soon.

vatsan-madhavan · 2020-03-20T18:10:38Z

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 😄).

bclothier · 2020-03-24T11:17:14Z

To clarify, as a part of Visual Studio 16.5 update?

weltkante · 2020-03-24T11:24:38Z

.NET Core Runtime/SDK installers are also available separately, so you don't have to wait for a VS update if you don't want to. (Assuming the fix "being in 3.1.3" means its fixed in the SDK and not in VS)

vatsan-madhavan · 2020-03-25T07:22:25Z

.NET Core 3.1.3 Release Notes

Download .NET Core 3.1

GeertvanHorrik · 2020-03-25T07:32:27Z

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

vatsan-madhavan · 2020-04-14T16:45:12Z

Closing as this is now fixed.

Kerfluffel · 2020-05-28T21:41:11Z

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?

nirzaf · 2020-05-29T00:12:24Z

Still, No Fixes Microsoft is working on this issue slower than windows 10, Better you migrate to Java

weltkante · 2020-05-29T05:58:46Z

@Kerfluffel no this is not the same issue, I suspect System.Web is not part of .NET Core (probably discontinued), so this error would be expected.

MatthewSteeples · 2020-08-06T17:11:01Z

This looks to have regressed with 3.1.400 (16.7 release)

jnm2 · 2020-08-07T00:24:18Z

Same here. All WPF projects that reference DevExpress WPF libraries started failing to build after updating from 3.1.302 to 3.1.400:

C:\Program Files\dotnet\sdk\3.1.400\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=7cec
85d7bea7798e'. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAsse
mblyResolver that returns a valid assembly.'

ghost · 2020-08-10T07:44:48Z

With .NET Core 3.1.400, Visual Studio 16.7 and targeting net48, I've got the same error compiling from VS or from the command line.
C:\Program Files\dotnet\sdk\3.1.400\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(225,9): error MC1000: Erreur de build inconnue, '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.'

jnm2 · 2020-08-10T14:19:23Z

An open issue where this is being tracked is #3312.

vatsan-madhavan mentioned this issue Dec 4, 2019

After update to VS 16.4 projects stop compiling #2277

Closed

vatsan-madhavan mentioned this issue Dec 10, 2019

Add System.Reflection.PathAssemblyResolver support for 'retargetable' assemblies dotnet/runtime#730

Closed

arpitmathur added the issue-type-tracking-external To track dependencies with other teams or repos label Dec 12, 2019

arpitmathur added this to the 3.1.2 milestone Dec 12, 2019

vatsan-madhavan mentioned this issue Dec 16, 2019

Any WPF project lower than net461 with System.ValueTuple cannot be compiled #2320

Open

Kinnara mentioned this issue Jan 5, 2020

Can't build repo, gives error that System.Core v2.0.5.0 can'tbe found. Kinnara/ModernWpf#19

Closed

vatsan-madhavan closed this as completed Apr 14, 2020

jogibear9988 mentioned this issue May 10, 2020

work on linqpad6 support linq2db/linq2db.LINQPad#32

Merged

Kerfluffel mentioned this issue May 29, 2020

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

Closed

nzain mentioned this issue Jun 25, 2020

Microsoft.WinFX.targets Unknown build error Could not find assembly 'mscorlib' #3183

Closed

vatsan-madhavan mentioned this issue Jun 29, 2020

All source code cannot be built. microsoft/WPF-Samples#302

Open

ghost locked as resolved and limited conversation to collaborators Apr 13, 2022

Updating to 16.4 from 16.3.x causes build issues with WPF project file. #2274

Updating to 16.4 from 16.3.x causes build issues with WPF project file. #2274

Comments

olivegamestudio commented Dec 4, 2019

zplan commented Dec 4, 2019 • edited Loading

olivegamestudio commented Dec 4, 2019

zplan commented Dec 4, 2019 • edited Loading

vatsan-madhavan commented Dec 4, 2019

vatsan-madhavan commented Dec 4, 2019

olivegamestudio commented Dec 4, 2019 • edited Loading

nguerrera commented Dec 4, 2019 • edited Loading

njannink commented Dec 4, 2019

nguerrera commented Dec 4, 2019 • edited Loading

nguerrera commented Dec 5, 2019

zplan commented Dec 6, 2019 • edited Loading

pieterphilippaerts commented Dec 6, 2019

siegfriedpammer commented Dec 13, 2019

pieterphilippaerts commented Dec 13, 2019

zplan commented Dec 13, 2019 • edited Loading

Dunge commented Dec 16, 2019 • edited Loading

ds1709 commented Dec 19, 2019

bclothier commented Dec 22, 2019

zplan commented Jan 17, 2020

Nukepayload2 commented Jan 22, 2020 • edited Loading

vatsan-madhavan commented Jan 22, 2020 • edited Loading

Nukepayload2 commented Jan 23, 2020

jogibear9988 commented Jan 29, 2020 • edited Loading

vatsan-madhavan commented Jan 30, 2020

GeertvanHorrik commented Mar 7, 2020

ds1709 commented Mar 7, 2020

MichaeIDietrich commented Mar 7, 2020 • edited Loading

ds1709 commented Mar 8, 2020

kopfsick commented Mar 16, 2020

nirzaf commented Mar 16, 2020

zmj commented Mar 19, 2020

czdietrich commented Mar 19, 2020

AdamVasPrezi commented Mar 19, 2020

vatsan-madhavan commented Mar 19, 2020

The point of fix-consumption

Where is the fix made?

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

What happened ?

GeertvanHorrik commented Mar 20, 2020

vatsan-madhavan commented Mar 20, 2020

bclothier commented Mar 24, 2020

weltkante commented Mar 24, 2020 • edited Loading

vatsan-madhavan commented Mar 25, 2020 • edited Loading

GeertvanHorrik commented Mar 25, 2020

vatsan-madhavan commented Apr 14, 2020

Kerfluffel commented May 28, 2020

nirzaf commented May 29, 2020 • edited Loading

weltkante commented May 29, 2020

MatthewSteeples commented Aug 6, 2020

jnm2 commented Aug 7, 2020

ghost commented Aug 10, 2020

jnm2 commented Aug 10, 2020

zplan commented Dec 4, 2019 •

edited

Loading

zplan commented Dec 4, 2019 •

edited

Loading

olivegamestudio commented Dec 4, 2019 •

edited

Loading

nguerrera commented Dec 4, 2019 •

edited

Loading

nguerrera commented Dec 4, 2019 •

edited

Loading

zplan commented Dec 6, 2019 •

edited

Loading

zplan commented Dec 13, 2019 •

edited

Loading

Dunge commented Dec 16, 2019 •

edited

Loading

Nukepayload2 commented Jan 22, 2020 •

edited

Loading

vatsan-madhavan commented Jan 22, 2020 •

edited

Loading

jogibear9988 commented Jan 29, 2020 •

edited

Loading

MichaeIDietrich commented Mar 7, 2020 •

edited

Loading

weltkante commented Mar 24, 2020 •

edited

Loading

vatsan-madhavan commented Mar 25, 2020 •

edited

Loading

nirzaf commented May 29, 2020 •

edited

Loading