Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating to 16.7 from 16.6.5 causes build issues with WPF project file. #3312

Closed
53m1k0l0n opened this issue Aug 6, 2020 · 23 comments
Closed
Labels
Bug Product bug (most likely)

Comments

@53m1k0l0n
Copy link

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

C:\Program Files\dotnet\sdk\3.1.400\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets 225

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.

@ryalanms
Copy link
Member

ryalanms commented Aug 6, 2020

This looks like: dotnet/sdk#12710.

@ryalanms ryalanms added the Bug Product bug (most likely) label Aug 6, 2020
@jnm2
Copy link

jnm2 commented Aug 7, 2020

This can be worked around by adding a global.json file next to the solution file (not next to the project file unless they are in the same folder). This causes the latest 3.1.3xx SDK to be used, only using 3.1.300 if you have nothing later on the machine within 3.1.3xx:

{
  "sdk": {
    "version": "3.1.300",
    "rollForward": "latestPatch"
  }
}

@vatsan-madhavan
Copy link
Member

@GrabYourPitchforks Do you have any concerns with usage of older SDK's esp. from the standpoint of missing security fixes etc. ?

@GrabYourPitchforks
Copy link
Member

If you lock yourself to a specific version (say, 3.1.300), you'll want a plan to update as new security patches are released and older versions fall out of support. If you instead allow the version to float (3.1.xxx), this becomes a bit easier.

More info: https://docs.microsoft.com/dotnet/core/tools/global-json and https://dotnet.microsoft.com/download/dotnet-core/3.1 (see the security-patch label and associated SDK versions).

For support policies, see https://dotnet.microsoft.com/platform/support/policy/dotnet-core. In summary, we currently have two supported release trains: 2.1.x and 3.1.x. As soon as a new patch is released, the old patch falls out of support. That is, 2.1.x falls out of support the minute 2.1.(x + 1) is released; and 3.1.x falls out of support the minute 3.1.(x + 1) is released.

@jnm2
Copy link

jnm2 commented Aug 7, 2020

The global.json above floats to the latest patch for 3.1.3xx. It's not possible to use 3.1.400 because the SDK is the cause of the bug, unless someone finds another workaround. This is what global.json is for, after all: working around version dependencies. It would be ideal if there was a way to say "3.1.xxx but pretend 3.1.400 isn't installed," but the above is the best we can do.

@GrabYourPitchforks Are you talking about runtimes or SDKs? Is the only supported 3.1 SDK the one that currently can't be used, 3.1.400?

@vatsan-madhavan
Copy link
Member

@jnm2 The reason I asked @GrabYourPitchforks for input is to make sure that if workarounds have to be put forth in the interim (for e.g. 'use 3.1.300 in global.json until a fix is shipped in an upcoming servicing milestone'), then such workarounds do not implicitly set back security. Your questions are very helpful to puzzle out what workarounds would be viable, if any.

@jnm2
Copy link

jnm2 commented Aug 7, 2020

@vatsan-madhavan Cool. To be clear, my workaround does not use 3.1.300 if 3.1.301 or 3.1.302 are installed. This is due to "rollforward": "latestPatch" as opposed to "rollforward": "patch". Also, this doesn't affect the rollforward policy of the published application, only of the SDK itself which is used during compilation and publishing.

@walterlv
Copy link
Contributor

walterlv commented Aug 10, 2020

This issue may be the same one as #2320 . And I append the 3.1.400 version into the issue.

Error MC1000 Unkown build error “Could not find assembly 'System.Core, 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.” Walterlv.Demo.CannotCompileWithValueTuple C:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets 225

@jnm2
Copy link

jnm2 commented Aug 10, 2020

@tuke307 Why did you downvote the workaround? Is there a better workaround than using the 3.1.302 SDK that allows us to continue working?

@tuke307
Copy link

tuke307 commented Aug 10, 2020

@jnm2 it's not working for me. I set up the global.json with the old 3.1.3 sdk, but it's not working

@jnm2
Copy link

jnm2 commented Aug 10, 2020

@tuke307 Does dotnet --info show that at least one 3.1.3xx SDK is installed? If not, you have to install it. "Not working" doesn't tell me anything. Did it have no effect at all? Then you probably didn't put the global.json file in the right place. Did it result in Visual Studio refusing to load the project? Then you probably need to install the SDK. Is there a new build failure message? What's the specific error message or behavior?

@zastrowm
Copy link

zastrowm commented Aug 10, 2020

@jnm2 I'm seeing it not work as well, but it's because the right SDK version isn't being used.

rollFoward is seemingly having no affect, and dotnet --info is reporting Version: 3.1.400 even though it's being run in the same directory as global.json.

I'm still investigating.

@zastrowm
Copy link

zastrowm commented Aug 10, 2020

This is the odd behavior that I'm seeing; note that global.json and the solution are in the same directory, and the commands are executed from within that same directory.

For this global.json:

{
  "sdk": "3.1.201",
  "rollForward": "disable"
}

I get this output from dotnet --info:

``` dotnet --info .NET Core SDK (reflecting any global.json): Version: 3.1.400 Commit: 035fb2aa2f

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19041
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.1.400\

Host (useful for support):
Version: 3.1.6
Commit: 3acd9b0cd1

.NET Core SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.400 [C:\Program Files\dotnet\sdk]
2.1.801 [C:\Program Files\dotnet\sdk]
2.2.106 [C:\Program Files\dotnet\sdk]
3.1.201 [C:\Program Files\dotnet\sdk]
3.1.400 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

</details>

I just got done uninstalling a bunch of earlier dotnet sdks (mostly old 2.* versions), but `dotnet` doesn't seem to be applying `global.json` for some reason.

@jnm2
Copy link

jnm2 commented Aug 10, 2020

@zastrowm Your global.json does not follow the schema. "sdk" is an object, not a string, and "rollForward" goes inside it. See https://docs.microsoft.com/en-us/dotnet/core/tools/global-json.

@Dunge
Copy link

Dunge commented Aug 10, 2020

I have the same error with VS 16.7 in a Net Framework WPF application targeting net 4.7.2 but using the Microsoft.NET.Sdk.WindowsDesktop project type in the new csproj format.

VS 16.6 didn't have the issue, and VS 16.8 Preview don't have the issue either!

I can't use the workaround mentioned above since our project is NOT targeting netcore.

@zastrowm
Copy link

@jnm2 thanks, I'm an idiot :|

Sorry for derailing the conversation - that was the issue; it also explains why we never got early build failures when we didn't have the SDK installed....

@jnm2
Copy link

jnm2 commented Aug 10, 2020

@zastrowm I know the feeling. No worries!

@tuke307 Does this solve your issue too? Did you try pasting the workaround I posted exactly?

@jnm2
Copy link

jnm2 commented Aug 10, 2020

@Dunge

I can't use the workaround mentioned above since our project is NOT targeting netcore.

Our project is not targeting .NET Core, and yet we're using the .NET Core SDK to build it. The same applies to you if you are using the SDK-style csproj (Microsoft.NET.Sdk or Microsoft.NET.Sdk.WindowsDesktop, etc). The workaround I posted works regardless of what framework you are targeting.

@Dunge
Copy link

Dunge commented Aug 10, 2020

@jnm2

Ok thank you, I had the global.json next to the .csproj and not in the .sln folder, hence why it wasn't working. I also didn't have 3.1.300 installed, but pointing to 3.1.201 (my latest installed before 3.1.400) worked. I guess this file will remain until MS release a new fixed update.

@jnm2
Copy link

jnm2 commented Aug 11, 2020

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. I'm now able to build without a global.json file.

@53m1k0l0n
Copy link
Author

I have now tested several projects, the bug seems to be fixed.

@tomdierkes
Copy link

Visual Studio 16.7.5 and SDK 3.1.402 seem to reintroduce just this issue/bug (WPF project file will just NOT compile:

error MC1000: Unkown build error, "Could not find type 'Microsoft.EntityFrameworkCore.Infrastructure.DesignTimeProviderServicesAttribute' ..."

).

@DanFTRX
Copy link

DanFTRX commented Oct 7, 2020

@tomdierkes I don't think thats the same issue. I would suggest opening a new ticket.

@ghost ghost locked as resolved and limited conversation to collaborators Apr 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug Product bug (most likely)
Projects
None yet
Development

No branches or pull requests