Skip to content

Enable registry properties#7621

Merged
rokonec merged 2 commits into
dotnet:mainfrom
rainersigwald:registry-properties
May 26, 2022
Merged

Enable registry properties#7621
rokonec merged 2 commits into
dotnet:mainfrom
rainersigwald:registry-properties

Conversation

@rainersigwald

Copy link
Copy Markdown
Member

On non-Windows OSes, return empty, as we had been doing in .NET Core before.

This enables more project types to evaluate and match .NET Framework MSBuild's results when on Windows.

Fixes an issue reported via IM by @dfederm.

On non-Windows OSes, return empty, as we had been doing in .NET Core
before.

This enables more project types to evaluate and match .NET Framework
MSBuild's results when on Windows.
@rainersigwald rainersigwald force-pushed the registry-properties branch from 15c4dc2 to 13079b1 Compare May 13, 2022 16:08
While looking at registry properties I noticed these were also disabled.
Same logic applies for enabling them.

[Fact]
[PlatformSpecific(TestPlatforms.Windows)]
[SupportedOSPlatform("windows")]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What's the difference between these?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

The former disables the test on non-Windows platforms (via Arcade magic). The latter silences the warnings about using Windows-only APIs. As far as I could tell from the API docs, there's not a way to tell the OS-checking analyzer about another attribute that has the same meaning as SupportedOSPlatform.

// .NET Core MSBuild used to always return empty, so match that behavior
// on non-Windows (no registry), and with a changewave (in case someone
// had a registry property and it breaks when it lights up).
if (!NativeMethodsShared.IsWindows || !ChangeWaves.AreFeaturesEnabled(ChangeWaves.Wave17_4))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do you need the ifdef here? People are opted in anyway, so it won't affect anyone unless they disable the change wave, and I don't think people normally do that. Or maybe just plan to remove the ifdef with the change wave? If so, that should be in a comment so we remember.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Same for other cases.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Why bother doing the runtime check when we're on .NET Framework and know a priori that we're on Windows?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could also be on mono, not that you necessarily care. I imagine the win32 check was a real "on windows" check. Other reason is to unify the code paths, which I generally think positive.

Comment thread src/Build/Evaluation/IntrinsicFunctions.cs
@rainersigwald rainersigwald added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label May 16, 2022
@rokonec rokonec merged commit 40e5b0a into dotnet:main May 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants