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

.NET 6.0.101 breaks GENERIC_MATH_FEATURE/PreviewFeatures functionallity #62840

Closed
samtrion opened this issue Dec 15, 2021 · 18 comments · Fixed by #63599
Closed

.NET 6.0.101 breaks GENERIC_MATH_FEATURE/PreviewFeatures functionallity #62840

samtrion opened this issue Dec 15, 2021 · 18 comments · Fixed by #63599

Comments

@samtrion
Copy link

Description

After updating to the latest Visual Studio 2022 version on 12/14/21 and .NET SDK version 6.0.101, the project could not be built. Since the interfaces IBinaryNumber, IComparisonOperators & IFloatingPoint could no longer be found in the project https://github.com/samtrion/netevolve-guard

Reproduction Steps

  • Trying to build project with .NET 6.0.101

Expected behavior

Project can continue to be built successfully.

Actual behavior

Project can no longer be created because the interfaces IBinaryNumber, IComparisonOperators & IFloatingPoint are not available.

Regression?

Yes, with the mentioned workaround the creation of the project works.

Known Workarounds

Disabled the rollForward via the global.json.

{
  "sdk": {
    "version": "6.0.100",
    "rollForward": "disable"
  }
}

Configuration

  • Which version of .NET is the code running on?
    So far always the latest SDK version of .NET 6
  • What OS and version, and what distro if applicable?
    Windows 10 & Windows 11
  • What is the architecture (x64, x86, ARM, ARM64)?
    x64
  • Do you know whether it is specific to that configuration?
    Was able to recreate the issue both locally and on the GitHub Actions Runner.

Other information

No response

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Dec 15, 2021
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@ghost
Copy link

ghost commented Dec 15, 2021

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

After updating to the latest Visual Studio 2022 version on 12/14/21 and .NET SDK version 6.0.101, the project could not be built. Since the interfaces IBinaryNumber, IComparisonOperators & IFloatingPoint could no longer be found in the project https://github.com/samtrion/netevolve-guard

Reproduction Steps

  • Trying to build project with .NET 6.0.101

Expected behavior

Project can continue to be built successfully.

Actual behavior

Project can no longer be created because the interfaces IBinaryNumber, IComparisonOperators & IFloatingPoint are not available.

Regression?

Yes, with the mentioned workaround the creation of the project works.

Known Workarounds

Disabled the rollForward via the global.json.

{
  "sdk": {
    "version": "6.0.100",
    "rollForward": "disable"
  }
}

Configuration

  • Which version of .NET is the code running on?
    So far always the latest SDK version of .NET 6
  • What OS and version, and what distro if applicable?
    Windows 10 & Windows 11
  • What is the architecture (x64, x86, ARM, ARM64)?
    x64
  • Do you know whether it is specific to that configuration?
    Was able to recreate the issue both locally and on the GitHub Actions Runner.

Other information

No response

Author: samtrion
Assignees: -
Labels:

area-System.Numerics, untriaged

Milestone: -

@danmoseley
Copy link
Member

@krwq

@Chamberlain91
Copy link

I have also suffered this error in my hobby project. I'm unsure how to install 6.0.100 again. The SDK installer complains I have another version of the project and adding that global.json gives me:

Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
  * You intended to execute a .NET program:
      The application 'build' does not exist.
  * You intended to execute a .NET SDK command:
      A compatible installed .NET SDK for global.json version [6.0.100] from [C:\Users\<my_user_project_path>\global.json] was not found.
      Install the [6.0.100] .NET SDK or update [C:\Users\<my_user_project_path>\global.json] with an installed .NET SDK:
        2.1.701 [C:\Program Files\dotnet\sdk]
        2.1.801 [C:\Program Files\dotnet\sdk]
        2.1.802 [C:\Program Files\dotnet\sdk]
        3.0.100-preview9-014004 [C:\Program Files\dotnet\sdk]
        5.0.100-rc.2.20479.15 [C:\Program Files\dotnet\sdk]
        6.0.101 [C:\Program Files\dotnet\sdk]

@samtrion
Copy link
Author

I have also suffered this error in my hobby project. I'm unsure how to install 6.0.100 again. The SDK installer complains I have another version of the project and adding that global.json gives me:

Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
  * You intended to execute a .NET program:
      The application 'build' does not exist.
  * You intended to execute a .NET SDK command:
      A compatible installed .NET SDK for global.json version [6.0.100] from [C:\Users\<my_user_project_path>\global.json] was not found.
      Install the [6.0.100] .NET SDK or update [C:\Users\<my_user_project_path>\global.json] with an installed .NET SDK:
        2.1.701 [C:\Program Files\dotnet\sdk]
        2.1.801 [C:\Program Files\dotnet\sdk]
        2.1.802 [C:\Program Files\dotnet\sdk]
        3.0.100-preview9-014004 [C:\Program Files\dotnet\sdk]
        5.0.100-rc.2.20479.15 [C:\Program Files\dotnet\sdk]
        6.0.101 [C:\Program Files\dotnet\sdk]

You can find the download here - https://dotnet.microsoft.com/en-us/download/dotnet/6.0#version_1

@martincostello
Copy link
Member

I also logged this in the SDK repo: dotnet/sdk#23073

@danmoseley
Copy link
Member

cc @safern in case he's around tomorrow and has insights. We shouldn't have broken this...

@safern
Copy link
Member

safern commented Dec 16, 2021

Since we serviced the ref pack we might have broken it because of file versions so with 6.0.1 assembly conflict resolution might prefer the System.Runtime in the ref pack rather than the one in the System.Runtime.Experimental package.

Looking to confirm this theory and see what we can do for next servicing releases.

@safern
Copy link
Member

safern commented Dec 17, 2021

I was able to confirm that theory with the repository shared on the issue, this is the output from the conflict resolution:

Encountered conflict between 'Reference:C:\Users\safern\.nuget\packages\system.runtime.experimental\6.0.0\ref\net6.0\System.Runtime.dll' and 'Reference:C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.1\ref/net6.0/System.Runtime.dll'. Choosing 'Reference:C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.1\ref/net6.0/System.Runtime.dll' because file version '6.0.121.56705' is greater than '6.0.121.52210'.

You can workaround this if you want to use 6.0.101 SDK by adding this target to the projects that want to use System.Runtime.Experimental (in the case of netevolve-guard, your .Experimental and .Experimental.Tests projects) you can add it in a common location like a Directory.Build.targets file:

  <Target Name="RemoveSystemRuntimeFromRefPack"
          BeforeTargets="_HandlePackageFileConflicts"
          Condition="'@(Reference -> WithMetadataValue('NugetPackageId', 'System.Runtime.Experimental'))' != ''">
    <ItemGroup>
      <Reference Remove="@(Reference)"
                 Condition="$([System.String]::Copy(%(Reference.Identity)).Contains('System.Runtime.dll')) and
                            '%(Reference.NuGetPackageId)' == 'Microsoft.NETCore.App.Ref'" />
    </ItemGroup>
  </Target>

@ericstj @dsplaisted is there a way to tell package conflict file resolution to always choose the asset from System.Runtime.Experimental via a platform manifest or package override file in the ref pack? Or do we have to service System.Runtime.Experimental every time we service the ref pack?

@safern safern added this to the 6.0.x milestone Dec 17, 2021
@ericstj
Copy link
Member

ericstj commented Dec 17, 2021

We intentionally tried to address this here: https://github.com/dotnet/runtime/pull/55678/files#diff-41acba6267202db943fa29d434bb231021a7b8b47b63c990bd61708111c67515R33

I can't see where we're addressing conflict resolution in the current approach, did that get removed?

@ericstj
Copy link
Member

ericstj commented Dec 17, 2021

Rereading above, it looks like folks didn't understand how ref-pack servicing / file-versions worked when we did it initially.

6.0.121.56705' is greater than '6.0.121.52210'

I think we should just modify how much gap we bump the experimental reference assembly to make sure it will be higher than servicing.

@safern
Copy link
Member

safern commented Dec 17, 2021

Should we just set the minor version of the file version for System.Runtime.Experimental so that we guarantee it is always greater?

@tannergooding
Copy link
Member

Should we just set the minor version of the file version for System.Runtime.Experimental so that we guarantee it is always greater?

I don't think there is a particular preference provided we know we won't need to publish some actual v6.1 version of the things at any point.

@ericstj
Copy link
Member

ericstj commented Jan 3, 2022

I think bumping the minor version of only the file version should be fine. Fix should go here:

<FileVersion>$(_FileVersionMaj).$(_FileVersionMin).$([MSBuild]::Add($(_FileVersionBld), 100)).$(_FileVersionRev)</FileVersion>

And we should be able to remove the incrementing of _FileVersionBld

@safern
Copy link
Member

safern commented Jan 3, 2022

Let me know if help is needed to drive fixing this and porting it. We have till Monday to make the cut for 6.0.2

@tannergooding
Copy link
Member

Do I just need to put up a PR against main or do I need to also target some existing servicing branch?

@tannergooding
Copy link
Member

Likewise, is the minor version differing going to cause problems with version resolution or if we do end up exposing an actual v6.1 in the future?

@safern
Copy link
Member

safern commented Jan 3, 2022

Do I just need to put up a PR against main or do I need to also target some existing servicing branch?

We need to put it against main and against release/6.0 and then go over through servicing approval.

Likewise, is the minor version differing going to cause problems with version resolution or if we do end up exposing an actual v6.1 in the future?

It shouldn't be a problem. If needed we can always bump the minor version for the file version attribute on v6.1 to something like 6.200.x

@ghost ghost added in-pr There is an active PR which will close this issue when it is merged and removed in-pr There is an active PR which will close this issue when it is merged labels Jan 8, 2022
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Jan 10, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jan 11, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Feb 10, 2022
@tannergooding tannergooding removed the untriaged New issue has not been triaged by the area owner label Jun 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants