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

Recognize .NET 7 when installed #1197

Merged
merged 1 commit into from
Jun 30, 2022
Merged

Recognize .NET 7 when installed #1197

merged 1 commit into from
Jun 30, 2022

Conversation

CharliePoole
Copy link
Collaborator

@CharliePoole CharliePoole commented Jun 30, 2022

Re-merging the fix for #1193 into the new version3 branch

@CharliePoole CharliePoole merged commit a1bfef7 into version3 Jun 30, 2022
@@ -201,6 +201,8 @@ private Version GetClrVersionForFramework(Version frameworkVersion)
return new Version(5, 0, 1);
case 6:
return new Version(6, 0, 0);
case 7:
return new Version(7, 0, 0);
Copy link

@AbhitejJohn AbhitejJohn Sep 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CharliePoole : Sorry I'm getting to this so late, I followed this here based on the comments here. I was curious if this would be a problem once .NET 8 (and future versions of .NET) get released...
/cc: @OsirisTerje

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it would, at least for anyone continuing to use 3.15.2 at that point. However, subsequent changes, to be released in 3.16, eliminated throwing of an exception when the runtime is not recognized. In addition, version 4.0 code eliminates this call entirely, dropping the need for the CLR version entirely. Both of the above are superior, in my opinion, to the often suggested option of using <MajorVersion>.0.0 because that involves predicting Microsoft's future actions.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes a lot of sense. Glad the newer versions have this fixed up.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CharliePoole I'm hitting this again with .NET 8 preview installed. How do I get VS/dotnet test to use 3.16?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's based on the version of the NUnit VS adapter you are using. Check with @OsirisTerje on that project.

Copy link
Member

@OsirisTerje OsirisTerje Feb 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@madelson We need a new version of the engine, 3.16.3. It should be released any day now, and then version 4.4.0 of the adapter will have this embedded. It will be released immediately after the 3.16.3

@CharliePoole CharliePoole deleted the issue-1193 branch January 1, 2023 14:46
@OsirisTerje
Copy link
Member

@AbhitejJohn Version 3.16.3 of the engine/console is out now, and it accepts all higher versions, and the adapter 4.4.0 is out (beta.1 now, but the non-beta will be released this weekend,) with the 3.16.3 engine, so there will be no further issues with that one either. See https://docs.nunit.org/articles/vs-test-adapter/AdapterV4-Release-Notes.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants