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
Remove some version hard-coding in the OSPlatformTranslator #4577
Comments
Can we get this in for 4.1 ? |
@stevenaw We cannot simply use As with new versions of Windows, when Windows10 eventually comes out we would need to add that, including how to detect this. There seems no logic in MS version numbers. One only has to look at OS platform where Windows10 is 10.0.22000, nobody knows what Windows12 will identify as. One option would be to drop the translation and convert the MS attributes in a modified new platform attribute which only checks if the version returned by MS is larger than the specified one. That way we can check minor versions as well and will be future proof. |
Quite right @manfred-brands . The issue title was a bit hastily-worded, but we can't get rid of the hard-coding entirely in OSPlatformTranslator. I'd been thinking though, that for the common case where NUnit encounters Based on the discussion in the linked SDK issue it also sounds like @manfred-brands @OsirisTerje I think I'm connecting the right dots here but I'd welcome a second read of dotnet/sdk#37220 or opinion on if there's any simplification on the NUnit side here. |
@stevenaw I did read that article and they say
Hence my suggestion to decode the version numbers and compare that to the running OS version. If you agree, I can work on that. |
Oh ok thanks for explaining @manfred-brands I may've missed that. That sounds like a better idea if you think it'll work 😀 |
@manfred-brands @stevenaw Should this be moved to e.g. 4.2 ? |
I'm alright with that. |
No problem moving milestone. I actually forgot about the ticket. |
In #4574 and #4569 we added some hard-coded version numbers in the OSPlatformTranslator to fix a few things in NUnit 4.0.1.
It should be alright in the short-term as new major versions of Windows are relatively infrequent, however we should see if we can remove some of the hard-codings to minimize the chance that a new version of Windows will require a new version of the framework to work with it.
We should also ensure that the mapping code can account for any changes in the SDK for how a TFM such as
{version}-windows
may map to a compiler-generatedSupportOSPlatform
attribute that may come out of this issue: dotnet/sdk#37220One option could be to see if we can make use of
[Platform("Win")]
.The text was updated successfully, but these errors were encountered: