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

What is the behavior one gets on browser wasm before this change? Would that behavior be good enough?

(I agree we need to disable the test.)

@jkotas It'll throw

System.EntryPointNotFoundException : SystemNative_INotifyInit assembly:<unknown assembly> type:<unknown type> member:(null)

SystemNative_INotifyInit assembly: type: member:(null)

Is it the case even after #38368 ?

SystemNative_INotifyInit assembly: type: member:(null)

Is it the case even after #38368 ?

It'll throw PNSE. I guess that raises the question, should HostFileChangeMonitor also throw PNSE?

I do not think we need to be transitively updating all places that depend on unsupported functionality, unless there is significant value in doing so (e.g. allow large amount of code to be linked away in frequently used library).

I do not think we need to be transitively updating all places that depend on unsupported functionality, unless there is significant value in doing so (e.g. allow large amount of code to be linked away in frequently used library).

I think we should attempt to get as close to the top of the public API as possible. In this case, it's pretty cheap to do, so why not?

I do not think we need to be transitively updating all places that depend on unsupported functionality

I think there is almost always value in being explicit in public APIs if they throw PNSE or not. It's not only about size but more about making it easier for human reviews and tooling to extract this kind of information.

I think there is almost always value in being explicit in public APIs if they throw PNSE or not

I agree with that for the inbox libraries.

System.Runtime.Caching is independent nuget package that happens to live in dotnet/runtime (we are shipping the org structure). The independent nuget packages should prefer to be platform neutral and depend on the support matrix of the underlaying platform-specific libraries where possible.

What if we add a check to the HostFileMonitor constructor:

if (RuntimeInformation.IsOSPlatform(OSPlatform.Create("BROWSER"))
   throw new PlatformNotSupportedException();

Then the assembly could stay platform neutral.

Do you expect that every nuget package out there should add a check like this around a call to API that's unsupported on wasm?

If not, we should not be doing this in our nuget packages either.

Yes I think that would be something a nuget package should do to disable functionality that doesn't work on wasm/browser.

That is a very high tax on the ecosystem as a whole.

Also, it is a encouraging bad pattern that is not future proof. If a future version of webassembly adds support for some of these, it means everybody has to do a replat.

A better pattern for this is to catch PlatformNotSupported exception and convert it in more appropriate exception. This only makes sense when there is a more appropriate exception - not the case here.

I still think it's better to be explicit as most users probably treat our System.* packages as special :)

In this specific case it's pretty unlikely browsers would add something like an inotify API since there's no filesystem at all, we're using an emulation layer provided by emscripten.

cc @ericstj This is related to our discussion about how far we should be going with platform special casing.

We shouldn't be doing this. Even the type you're throwing from has another path through it where the caller can provide their own implementation by setting ObjectCache.Host.

We shouldn't be projecting our platform-specific characteristics up the stack. If we find it important enough for libraries to react to this, we should design capability APIs that they can use, like was done for Ref.Emit.

Even the type your throwing from has another path through it where the caller can provide their own implementation by setting ObjectCache.Host.

@ericstj I'm not sure what you mean by that?

Look for host.GetService(typeof(IFileChangeNotificationSystem)) in HostFileChangeMonitor.cs. This can return user-supplied implementation of file watcher that does not depend on any of the underlaying platform capabilities.

I see. In that case I think I agree we should just skip the tests only.