Consider marking `DllImportSearchPath` values that don't make sense outside Windows as `[SupportedOSPlatform("windows")]`

[elinor-fung]

Would it make sense to mark DllImportSearchPath values that don't make sense outside Windows as [SupportedOSPlatform("windows")]?

Originally posted by @MichalStrehovsky in #119287 (review)

Only DllImportSearchPath.AssemblyDirectory means anything on non-Windows.

[dotnet-policy-service]

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

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Investigate semantics of DllImportSearchPath attribute on Non-Windows platforms #11681

[huoyaoyuan]

A single DllImportAttribute can be used for defining P/Invoke for different platforms. Marking something as Windows-only may potentially be confusing.

[MichalStrehovsky]

A single DllImportAttribute can be used for defining P/Invoke for different platforms. Marking something as Windows-only may potentially be confusing.

Do you have an example in mind where one would define a DllImport with Windows-specific DllImportSearchPath and rely on the fact that these flags don't really do anything outside Windows?

I do have a counter-example in #119287 where there was an assumption that DllImportSearchPath would do the same thing on all platforms and it introduced a bug (that would be preventable since we upgrade notes from SupportedOSPlatform to warning and then to error in this repo).

[huoyaoyuan]

I can't find an example though. Nowadays it's not recommended to install dll into system32, or does Windows ship open source libraries in system32.