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

[Kerfluffel]

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?

_Originally posted by @Kerfluffel in https://github.com/dotnet/wpf/issues/2274#issuecomment-635623365_

[vatsan-madhavan]

Are you using a global.json that pins the project to 3.1.300? That’s more specific than “have most current .netcore”

The latest is 3.1.4 at this time, BTW.

[Kerfluffel]

I didn't add a global.json...sorry very new to this moving from .net framework 4.5.2. Is that in the project file? I searched solution and through the project file...no global.json found.

When I pulled the released version it seemed to install 3.1.300 so perhaps I have missed something. Checking...

Checked versions installed...I didn't realize the run time was different version but this is what I have:
Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

3.1.300 [C:\Program Files\dotnet\sdk]

[vatsan-madhavan]

https://docs.microsoft.com/en-us/dotnet/core/tools/global-json

You need sdk.version.
Place it in the root of your solution, similar to where NuGet.config would be placed.

[vatsan-madhavan]

Alternatively go to the folder where you want the global.json and type dotnet new globaljson --sdk-version 3.1.300

[weltkante]

is System.Web even part of .NET Core? I don't know exactly which package System.Web belongs to but WebForms has been discontinued.

[vatsan-madhavan]

I’ve seen and debugged one customer’s project that had references to a proprietary netstandard NuGet, and System.Web appeared (as a transitive dependency, I think) in the references list during markup compilation of a dependent project... that customer was migrating from netfx -> netcore as well when they came to us for help. The symptoms seemed somewhat similar.

This scenario could very well be different. I was hoping to eliminate one variable - namely SDK version - as a factor definitively since we know that older SDK’s have a bug in this area. Having a global.json guarantees that an older sdk isn’t involved in the build inadvertently.

[Kerfluffel]

created global.json in root of solution folder, restarted Studio - build error still occurs
{
"sdk": {
"version": "3.1.300"
}
}
Also I don't reference System.Web in the solution

[vatsan-madhavan]

Sorry that didn’t help. Are you able to share the build binary logs? Or better yet, can you share a simple project that reproduces the problem ?

Someone would have to investigate further.

http://aka.ms/msbuild/binary-log shows how to collect it.

In command line build using msbuild or dotnet , Adding /bl switch would generate it.

[Kerfluffel]

Thank you for that suggestion. I prefer not to post it publicly, though I was able to use the MSBuild Log Viewer to help better understand what is happening. If I understand the results correctly, the app I am migrating uses DevExpress WPF/NET Core tools; particularly for showing a chart. It seems to be the DevExpress tools referencing System.Web.

I confirmed by removing the code for the chart control, and its references. Now the compile error goes away. I am not sure if I am doing something wrong referencing the DevExpress tools, if there is an issue in their tools, or perhaps Studio has an issue compiling their tools. I plan to reach out to them but not sure exactly where the issue lies for resolution...perhaps there is a configuration piece I am not aware of. I will report back any progress.

Thanks for the assistance

[vatsan-madhavan]

Hmm.. Somehow DevExpress NuGet assemblies are resolving to their net452 versions. Are you definitely using .NET Core TFM and not inadvertently still using a .NET framework TFM somewhere?

[Kerfluffel]

At first I was targeting both netcoreapp3.1;net472.
Then I tried just the netcoreapp3.1
It still occurred and their assemblies are resolving to v452 even though I am targeting v472 for everything else. The only thing I can think of is they have changed charting to use new classes for .NET Core...since I am migrating old code, maybe it is still referencing older assemblies it shouldn't somehow. I have posted the question to them referencing this issue here as they would know best. I could easily be missing something learning as I go for all these new changes. Hopefully I am not creating a wild goose chase.

[vatsan-madhavan]

When you are targeting net472, the NuGet assets can come from a compatible lower version like net452.

Then I tried just the netcoreapp3.1
even though I am targeting v472 for everything else

If one project is switched to netcoreapp3.1, the closure of all its project-references have to be changed to netcoreapp3.1 as well. Those references cannot be left at net4xx...and still expect a and successful build...

[Kerfluffel]

Sorry for the delay, I have been working on this with the third party. We were able to clear this up, but it required changes to the project file by hand...I'm not sure which item does not create the correct structure for the project; either the third party, studio, nuget packages/manager, but forcing the packages to their proper targets seems to work. Perhaps I was supposed to do this by hand and wasn't aware of it. Anyways, the resulting project file code is attached (wasn't showing correctly here within the 'code' section)
projExerptSample.txt

Seems to be resolved. Thank you all for your help! The build log was a great debugging clue.