search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.19k stars 4.72k forks source link

Mark APIs as unsupported on Browser WASM #41087

Closed MaximLipnin closed 3 years ago

MaximLipnin commented 4 years ago

We can use UnsupportedOSPlatformAttribute("browser") attribute to mark unsupported APIs on Browser WASM so that the analyzer can provide warnings when developers accidentally call platform-specific APIs. Spec: https://github.com/dotnet/designs/pull/144

We use the scanner (https://github.com/dotnet/platform-compat) to gather the list of all the APIs throwing PNSE on Browser WASM at the moment. Below is the file containing ~4500 PNSE methods. pnse-17082020.txt

There can be some special cases:

Namespaces (L# in file above)

cc @steveisok @lewing

Dotnet-GitSync-Bot commented 4 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

ghost commented 4 years ago

Tagging subscribers to this area: @CoffeeFlux See info in area-owners.md if you want to be subscribed.

CoffeeFlux commented 4 years ago

area-VM-meta-mono seems like the wrong area for this since it's purely libraries, but I'm not sure what to use for something that applies to libraries as a whole. area-Meta also seems wrong...

ghost commented 4 years ago

Tagging subscribers to this area: @safern, @viktorhofer See info in area-owners.md if you want to be subscribed.

akoeplinger commented 4 years ago

@jeffhandley @adamsitnik while adding the [UnsupportedOSPlatform] attributes to the src a question came up what to do when the method we're annotating has multiple implementations (e.g. .Browser.cs, .Unix.cs and .Windows.cs).

Should we add the attribute to all the implementations in those cases? If we don't do that then regenerating the ref would remove the attribute if you're on a different platform.

jeffhandley commented 4 years ago

I've been encountering similar stuff with https://github.com/dotnet/runtime/pull/41209, where we're trying to get the runtime repo ready to receive the analyzer. We don't yet have a solid strategy for this scenario.

adamsitnik commented 4 years ago

Should we add the attribute to all the implementations in those cases?

This is what we have been doing so far.

jeffhandley commented 4 years ago

We have now filed https://github.com/dotnet/runtime/issues/41354 against the runtime repo to resolve the issues there for RC2.

MaximLipnin commented 4 years ago

It looks like the exception scanner doesn't gather PNSEs thrown from runtime, e.g. something that uses mono_error_set_platform_not_supported method. At least, I don't see appropriate APIs in the result file attached to the PR's description. In case of Browser, an example of such API could be Thread.Start() which invokes StartInternal -> ves_icall_System_Threading_Thread_StartInternal -> mono_error_set_platform_not_supported .

sigmarsson commented 3 years ago

Hi Seniors, Is there an alternative way to retrieve assembly version info on Wasm instead of FileVersionInfo ? That is not supported any more in the browser.

https://github.com/unoplatform/uno/issues/5916

marek-safar commented 3 years ago

@sigmarsson what about using RuntimeEnvironment.GetSystemVersion () ?

sigmarsson commented 3 years ago

@marek-safar i wish to retrieve either the calling or the executing assembly version.

sigmarsson commented 3 years ago

E.g.

image

marek-safar commented 3 years ago

I see, in that case, the closest approximation would be to read System.Reflection.AssemblyFileVersionAttribute from the assembly.

MaximLipnin commented 3 years ago

All the namespaces mentioned in this issue are covered so I'm closing it as completed