Closed MaximLipnin closed 3 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.
Tagging subscribers to this area: @CoffeeFlux See info in area-owners.md if you want to be subscribed.
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...
Tagging subscribers to this area: @safern, @viktorhofer See info in area-owners.md if you want to be subscribed.
@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.
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.
Should we add the attribute to all the implementations in those cases?
This is what we have been doing so far.
We have now filed https://github.com/dotnet/runtime/issues/41354 against the runtime repo to resolve the issues there for RC2.
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
.
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.
@sigmarsson what about using RuntimeEnvironment.GetSystemVersion ()
?
@marek-safar i wish to retrieve either the calling or the executing assembly version.
E.g.
I see, in that case, the closest approximation would be to read System.Reflection.AssemblyFileVersionAttribute from the assembly.
All the namespaces mentioned in this issue are covered so I'm closing it as completed
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/144We 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)
https://github.com/dotnet/runtime/pull/41085) serialization-related infrastructurehttps://github.com/dotnet/runtime/pull/41085) serialization-related infrastructurehttps://github.com/dotnet/runtime/pull/41263) false-positive, obsolete, serialization relatedhttps://github.com/dotnet/runtime/pull/41327) False Positivehttps://github.com/dotnet/runtime/pull/41328)https://github.com/dotnet/runtime/pull/41971) false-positivehttps://github.com/dotnet/runtime/pull/41330) False Positivehttps://github.com/dotnet/runtime/pull/41987) false-positivehttps://github.com/dotnet/runtime/pull/42030) False-positives/PNSE all mono/windows onlyhttps://github.com/dotnet/runtime/pull/41892)https://github.com/dotnet/runtime/pull/41888)https://github.com/dotnet/runtime/pull/41884) windows-specifichttps://github.com/dotnet/runtime/pull/42027) PNSE all platformscc @steveisok @lewing