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.

Sign up for GitHub

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

Jump to bottom

Cannot use Assert.Equals due to unmanaged constraint in Visual Basic #75063

Open
jaredpar opened this issue Sep 11, 2024 · 0 comments
Open

Cannot use Assert.Equals due to unmanaged constraint in Visual Basic #75063

jaredpar opened this issue Sep 11, 2024 · 0 comments
Labels
Area-Compilers Language-VB
Milestone
.NET 10

Comments

@jaredpar
Copy link
Member

Consider the following code:

Assert.Equal(Of Byte)(new Byte() { }, new Byte() { })

This is failing when upgrading to the latest xUnit. This is due to the addition of the unmanaged constraint in the core Assert.Equals API. That is not supported by VB and leads to the overload triggering

BC30649 '' is an unsupported type.

Short term going to work around this with some helper methods but need to consider how to address this longer term.
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Sep 11, 2024
@jaredpar jaredpar added this to the .NET 10 milestone Sep 11, 2024
@jaredpar jaredpar self-assigned this Sep 11, 2024
jaredpar added a commit to jaredpar/roslyn that referenced this issue Sep 12, 2024
@jaredpar
Upgrade xUnit
82344fc 
One of our NuGet audit alerts was rooted in our xUnit packages as they
only had `netstandard1.3` libraries. To resolve this alert I moved us to
newer versions of the package which had `netstandard2.0` libraries.

Upgrading the package revealed two problems in our code base:

1. The xUnit `Assert` APIs took advantage of the `unmanaged` constraint
   in a fwe places. That is not supported by Visual Basic and leads to
   errors on import. To work around this I inserted `AssertEx` thunks
   that our Visual Basic layer can call through. Longer term we will
   need to consider adding support for the constraint
   ([issue](dotnet#75063))
2. The xUnit APIs significantly increased their nullable reference type
   annotations. This caught a number of places where the tests were
   passing potentially null values to APIs that don't accept null. There
   were enough hits that I added `AssertEx` methods that handle the
   nullable case. In a few places though I just suppressed the warning.

The vulnerability: GHSA-cmhx-cq75-c4mj
@jaredpar jaredpar mentioned this issue Sep 12, 2024
Merged
jaredpar added a commit to jaredpar/roslyn that referenced this issue Sep 25, 2024
@jaredpar
Upgrade xUnit
021f67c 
One of our NuGet audit alerts was rooted in our xUnit packages as they
only had `netstandard1.3` libraries. To resolve this alert I moved us to
newer versions of the package which had `netstandard2.0` libraries.

Upgrading the package revealed two problems in our code base:

1. The xUnit `Assert` APIs took advantage of the `unmanaged` constraint
   in a fwe places. That is not supported by Visual Basic and leads to
   errors on import. To work around this I inserted `AssertEx` thunks
   that our Visual Basic layer can call through. Longer term we will
   need to consider adding support for the constraint
   ([issue](dotnet#75063))
2. The xUnit APIs significantly increased their nullable reference type
   annotations. This caught a number of places where the tests were
   passing potentially null values to APIs that don't accept null. There
   were enough hits that I added `AssertEx` methods that handle the
   nullable case. In a few places though I just suppressed the warning.

The vulnerability: GHSA-cmhx-cq75-c4mj
jaredpar added a commit that referenced this issue Sep 26, 2024
@jaredpar
Upgrade xUnit (#75068)
0b058f2 
* Upgrade xUnit

One of our NuGet audit alerts was rooted in our xUnit packages as they
only had `netstandard1.3` libraries. To resolve this alert I moved us to
newer versions of the package which had `netstandard2.0` libraries.

Upgrading the package revealed two problems in our code base:

1. The xUnit `Assert` APIs took advantage of the `unmanaged` constraint
   in a fwe places. That is not supported by Visual Basic and leads to
   errors on import. To work around this I inserted `AssertEx` thunks
   that our Visual Basic layer can call through. Longer term we will
   need to consider adding support for the constraint
   ([issue](#75063))
2. The xUnit APIs significantly increased their nullable reference type
   annotations. This caught a number of places where the tests were
   passing potentially null values to APIs that don't accept null. There
   were enough hits that I added `AssertEx` methods that handle the
   nullable case. In a few places though I just suppressed the warning.

The vulnerability: GHSA-cmhx-cq75-c4mj
@jaredpar jaredpar removed their assignment Oct 1, 2024
@jcouv jcouv removed the untriaged Issues and PRs which have not yet been triaged by a lead label Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Compilers Language-VB
Projects
None yet
Milestone
.NET 10
Development

No branches or pull requests
2 participants
@jaredpar @jcouv