-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Comments
This looks like: dotnet/sdk#12710. |
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"
}
} |
@GrabYourPitchforks Do you have any concerns with usage of older SDK's esp. from the standpoint of missing security fixes etc. ? |
If you lock yourself to a specific version (say, 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: |
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? |
@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. |
@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 |
This issue may be the same one as #2320 . And I append the 3.1.400 version into the issue.
|
@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? |
@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 |
@tuke307 Does |
@jnm2 I'm seeing it not work as well, but it's because the right SDK version isn't being used.
I'm still investigating. |
This is the odd behavior that I'm seeing; note that For this
I get this output from
```
dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 3.1.400
Commit: 035fb2aa2f
Runtime Environment: Host (useful for support): .NET Core SDKs installed: .NET Core runtimes installed:
|
@zastrowm Your global.json does not follow the schema. |
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!
|
@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.... |
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 ( |
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. |
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. |
I have now tested several projects, the bug seems to be fixed. |
Visual Studio 16.7.5 and SDK 3.1.402 seem to reintroduce just this issue/bug (WPF project file will just NOT compile:
). |
@tomdierkes I don't think thats the same issue. I would suggest opening a new ticket. |
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.
The text was updated successfully, but these errors were encountered: