Home: WebAssembly TFM support

[jeromelaban]

Details about Problem

There is no WebAssembly TFM available in NuGet, which makes the creation of libraries impossible at this point.

This prevent, for instance :

• https://github.com/nventive/Uno.ReactiveUI
• https://github.com/nventive/Uno.Rx.NET
• https://github.com/nventive/uno.mvvmlight
• https://github.com/nventive/uno.prism

from being ported back to their original repositories for reviews and enable proper support for WebAssembly.

This impacts all mono-wasm based projects that needs to have a NuGet ecosystem, as well as mono-wasm itself, for platform specific implementations (e.g. WebSockets, Bindings, etc...)

References

• This PR was closed: https://github.com/NuGet/NuGet.Client/pull/2159
• This issue discussed WebAssembly substantially: https://github.com/dotnet/corefx/issues/27417
• This mono PR that deals with nuget: https://github.com/mono/mono/issues/7839
• This .NET Standard issue: https://github.com/dotnet/standard/issues/1073

[rrelyea]

Thanks for creating this issue and linking to previous discussions.
The direction here won't be decided by NuGet alone. Looping in @richlander @terrajobst @mhutch @anangaur (likely missing some others)

[richlander]

I appreciate the desire and need for this. At present, we're going to stick with netstandard as the TFM.

There are two motivators for not making progress here:

• We are re-thinking how frameworks and platform targets are going to work in the .NET 5 world.
• Web assembly isn't a singular target. We expect people to want both client and headless scenarios.

In short, more water needs to go under the bridge in order for us to have confidence on burning a TFM. It isn't something to be taken lightly. I realize that it causes pain in the short term.

[jeromelaban]

@richlander I agree that it's not an issue to take lightly. The point is to somehow centralize this discussion as the issues have been spread out in many repos.

WebAssembly is indeed a large scenario, and sandboxed (browsers) and non-sandboxed (WASI+CLI) are to be considered, as well as would capabilities of the current WebAssembly environment (e.g. Threads or SIMD). The solution may not be a new TFM, in the same way Android/iOS/macOS TFMs may not be, with the complex versioning issues that are currently exhibited with their respective native and mono runtime dependencies.

This impacts the structure of libraries and their dependencies in a significant (breaking) way, with for instance with Rx which is currently build in a monolithic way, and cannot have netstandard 2.0 being an alias for a WebAssembly runtime.

[terrajobst]

To be clear, we're not saying no. We're saying "we don't have enough data to make a decision yet". TFMs can fragment the world. And my team in particular has caused TFM fatigue de luxe. So I hope you understand why this is giving us pause.

[weitzhandler]

@terrajobst can we at least have even a temporary generalized wasm TFM so we can start working with wasm on projects that require Rx or other frameworks? Right now it's impossible to even extend those frameworks without forking it.

[terrajobst]

I don’t think so. After it’s shipped it’s quasi permanent.

[richlander]

We are not going to do anything until we have confidence. No quasi-permanent solutions or known-not-right permanent solutions.

@terrajobst and I have been at the center of a lot of bad decisions (hopefully some good ones too, or just get rid of us!). There are times when we didn’t fully appreciate the ecosystem shaping role we have. There are many, many, things that should have a Wild West characteristic to them in our ecosystem. We want a 1000 flowers to bloom and all that.

TFMs are not like that. There should be as few as possible and no more. So many problems and hardship occur if we allow TFMs to proliferate.

While we appreciate that you folks are having pain now, it is small to the much more spread out pain that could occur if we make bad decisions on something as fundamental as a TFM.

@terrajobst has been enjoying my analogies lately ... let’s take another run at that ...

This is a bit like genetically engineering humans with a bunch of new blood types and not determining ahead of time whether any compatible blood types exist for the scenario when they are in the emergency room and need a blood transfusion. Oops! We didn’t want genetically engineered humans, anyway!

Did I do good @terrajobst?

[weitzhandler]

Thanks for your responses, they do make a lot of sense.
Can we just ask to prioritize this? Just bear in mind tat this issue means that wasm has broken NuGet.

[terrajobst]

Can we just ask to prioritize this? Just bear in mind tat this issue means that wasm has broken NuGet.

We're working on Web Assembly as a product, NuGet is a part of it but it's not at the top of our priority list ATM.

[weitzhandler]

Thanks for letting us know. Does help a lot!

[anangaur]

Related feature suggestion on developercommunity: https://developercommunity.visualstudio.com/content/idea/598559/webassembly-tfm.html

[gulbanana]

if the solution is to be something other than a new TFM that’s fine, but we do need a solution!

[gulbanana]

Another factor making it difficult to productionise blazor is testability. What would be ideal is a .net quasi-runtime which uses a webassembly host (v8?) to load mono.wasm and runs tests under that environment. Imagine a test project with <TargetFrameworks>netcoreapp3.0;monowasm</TargetFrameworks>, validating your components in both the server-side and client-side environments they might run on...

A TFM isn’t the only piece needed to make this work but it would certainly help.

[michael-hawker]

Want to call out the Windows Community Toolkit here as well.

It'd be great for project maintainers to just be able to accept a WASM project/build modification for their project than to create a bunch of work for folks coordinating across a fork.

FYI @onovotny, in case he has any input into these scenarios/processes.

[TheXenocide]

I've been following this discussion for awhile and still feel like there will need to be a solution for this at some point, but today I started pondering whether or not it would be appropriate to consider MonoWASM more of a runtime than a TFM? Surely there's still a framework difference between what is actually supported in WASM and what is supposed to be supported by .NET Standard 2.0, but perhaps it's worth considering whatever subset of the BCL winds up in the TFM to be more cross-platform (and therefore consumable as a dependency by some more inclusive subset like .NET Standard 2.0 or higher without needing to mash up TFMs and duplicate outputs into multiple TFMs in NuGet packages like PCL profiles had us doing), but then simultaneously allows us to provide runtime-specific implementations. Just as an example to illustrate the thought experiment for anybody not following, let's say there's a new TFM called "netsubset" that can be consumed by projects targeting netsubset, netstandard2.0+ or net472+. Then we have an RID like "monowasm" so we can make a single NuGet package with a single TFM and, if necessary, provide runtime-specific native implementations such that the Blazor version uses some JavaScript interop and the Windows version uses some C-compatible extern dll, etc.

Anyway, just some food for thought I wanted to get into the discussion before it passed out of my brain.

[TheXenocide]

Just a quick followup I forgot to mention, but this also allows a NuGet dependency of a Blazor-oriented class library to provide separate runtime-specific implementations for Client-side and Server-side Blazor without requiring multiple compilation passes, etc.

[mattleibow]

+1 on the RID. That is more accurate. I would have a .NET Standard library that has native dependencies. I would then but those native dependencies in a RID - one for mac, one for win and one for wasm.

[gulbanana]

According to https://github.com/dotnet/designs/pull/92, there will be no WASM TFM. I'm not sure how to write a library which is used from Blazor and Desktop but has APIs that should only be available in the Desktop build. This design document suggests using a RID to make the APIs throw when used in a browser :/

[TheXenocide]

@gulbanana that's not very far off from the recommendations for multi-platform targeting today.

[gulbanana]

Yeah, making library consumers do runtime feature detection seems to be the current path. Sucks for my industry though (line of business applications, lots of maintenance programmers who do not read API documentation).

[weitzhandler]

Related

[tmenier]

Just my $0.02. As a library developer I've been dealing with WASM related frustrations repeatedly. To me it comes down to a fundamental problem with these platforms "supporting" .NET Standard in the first place. Here's how .NET Standard is described in the docs:

.NET Standard allows libraries to build against the agreed on set of common APIs, ensuring they can be used in any .NET application—mobile, desktop, IoT, web, or anywhere you write .NET code.

When Blazor and other WASM-based platforms implement the standard but throw runtime exceptions for the large portions of it that they don't actually support, I don't think it's a stretch to say that it's taking the whole point of having a standard and throwing it out the window. Am I wrong here?

Even though having TFMs that reflect what these platforms _actually_ support would great for library devs, I understand there's a lot of complications with that. I'm hoping that a better solution is eventually arrived at though, because saying these platforms support .NET Standard seems flat-out incorrect to me.