TFM mappings for WebAssembly and MonoUE #2159

mhutch · 2018-04-12T20:47:41Z

Added TFMs for WebAssembly and Mono for Unreal Engine.

Like other Mono-based frameworks, these are compatible with netstandard 2.0.

rohit21agrawal · 2018-04-13T01:02:28Z

@joelverhagen you know this area, could you take a peek please?

joelverhagen · 2018-04-13T01:37:48Z

src/NuGet.Core/NuGet.Frameworks/FrameworkConstants.cs

@@ -68,6 +68,8 @@ public static class FrameworkIdentifiers
            public const string XamarinXboxOne = "Xamarin.XboxOne";
            public const string UAP = "UAP";
            public const string Tizen = "Tizen";
+            public const string WebAssembly = "WebAssembly";


Is this WebAssembly TFM really appropriate? What really defines the compatibility level between WebAssembly and .NET Standard 2.0? Said another way, is there an official compatibility matrix between WebAssembly and .NET Standard assemblies? Truth be told, I am pretty ignorant about .NET + WebAssembly (and WebAssembly in general). This is the closest thing I could find: https://github.com/xamarin/WebSharp.

At first glance, this seems overly generic and perhaps could be renamed to the tool that is interopping between .NET Standard assemblies and WebAssembly.

To be clear I am not totally pushing back on the name, just trying to understand the full picture.

It's a new framework based on the Mono runtime that runs in the browser and has access to browser APIs. See also https://github.com/mono/mono/tree/master/sdks/wasm. This is the framework used by Blazor.

netstandard compat level is the same as the Xamarin frameworks, i.e. unversioned and assumed to be latest.

cc @migueldeicaza @terrajobst

It might be more appropriate to name it MonoWebAssembly or MonoWasm

The WebAssembly target is compatible with .NET Standard 2, but it is a superset of that API, as it is provides many capabilities not found on .NET Standard 2, it is based on the various mobile profiles used by Xamarin.

I do not think that we need to brand this as a Mono web assembly, it is not an implementation specific profile.

A WebAssembly TFM would make sense if there were a stable subset of APIs specific to WebAssembly, a WebAssemblyStandard 1.0, such as this:

https://github.com/mono/mono/blob/master/sdks/wasm/bindings.cs#L21

But are we already in such a state to know about this ? Currently, I'm blocked in many occasions by the fact that making nuget packages is not possible, and also because I cannot reference a package that provides this Runtime class.

Similarly, should there be a WebAssemblyApp and MonoWebAssemblyApp ?

Even if there is only MonoWebAssembly or NetCoreWebAssembly to begin with, re-targetting to WebAssembly when it will make sense is now very easy, and could be dealt with the runtime nuget feature.

I agree with @jeromelaban that an abstract WebAssembly TFM would be like .NET Standard. Which also explains why I don't think we should have another one -- we started .NET Standard specifically to unify all existing portability mechanisms (Silverlight, PCL, contracts) into a single thing that was simpler & more viable (i.e. has enough APIs). Moving forward, we don't want specific TFM mappings anymore; rather an asset should only be considered compatible if it matches the project's TFM or the corresponding .NET Standard version.

Personally, I think we need a TFM that designates a particular implementation of web assembly, rather than the concept. And MonoWebAssembly sounds like a fine plan to me.

while MonoWebAssembly would be fine in practice, i want to note that as a library author the reasons i need a tfm here are not mono-specific. i need to make multitargeted builds which do not access certain features of .net standard (threading, filesystem) and instead use less efficient implementations or provide fewer features. these are limitations of wasm conceptually, not limitations of mono’s wasm implementation.

this doesn’t matter much since a hypothetical future with <TargetFrameworks>monowasm;corewasm<TargetFrameworks> would not be very costly

i need to make multitargeted builds which do not access certain features of .net standard (threading, filesystem) and instead use less efficient implementations or provide fewer features
these are limitations of wasm conceptually, not limitations of mono’s wasm implementation

I believe these are more the limitations of the browser then of WebAssembly itself. For example, I believe you could write a different WebAssembly host (perhaps something like wasmjit) that doesn't have these restrictions.

yes, i suppose it's a matter of what 'syscalls' (or DOM bindings) are exposed to the WASM host

joelverhagen · 2018-04-13T01:39:51Z

test/NuGet.Core.Tests/NuGet.Frameworks.Test/CompatibilityTests.cs

@@ -904,6 +904,8 @@ public void Compatibility_ProjectCannotInstallGenerationLibraries(string framewo
        [InlineData("xamarinxboxthreesixty")]
        [InlineData("xamarinwatchos")]
        [InlineData("xamarinxboxone")]
+        [InlineData("wasm")]


Can we have some tests asserting that wasm and monoue does not support .NET Standard 2.1? Essentially a test verifying the max .NET Standard version is exactly what is expected.

We don't do this for any of the other frameworks, and I suspect them to support 2.1 pretty quickly.

I'd love to delegate this information to the framework instead of centralizing it all in one place.

joelverhagen

⌚️

rohit21agrawal · 2018-04-23T19:22:50Z

@mhutch if you still want this PR to go in, can you please address the feedback?

mhutch · 2018-04-23T19:55:10Z

@rohit21agrawal re. the TFM name, see Miguel's response.

Re. the request for tests, none of the existing TFMs have the suggested tests, and I don't think wasm is any different than them.

danroth27 · 2018-05-11T18:55:23Z

@davidfowl

danroth27 · 2018-05-17T17:33:13Z

One concern with having a generic WebAssembly TFM is how would you reason about targeting WebAssembly in browsers vs running in other environments that support WebAssembly but don't have the same limitations? For example, what if you are running on WebAssembly in Node or in an Electron app?

terrajobst · 2018-05-17T18:15:16Z

Two questions:

Which API surface/platform does wasm represent?
What's the mapping between .NET Standard and wasm?

marek-safar · 2018-05-18T08:50:35Z

@terrajobst

The API surface will probably closest to the latest netcore
What do you mean by mapping? It'll be netstandard 2 compatible if that's what you are asking

jeromelaban · 2018-05-26T15:44:54Z

@marek-safar it will be close to netstandard2.0, but it will have web assembly specific apis (https://github.com/mono/mono/blob/8de852ea9e611c3e841d33ad26dde8bd034e4325/sdks/wasm/bindings.cs) so it should be "mono5.x-wasm1.0" ?

marek-safar · 2018-05-28T07:55:49Z

That's fine, we'll just expose this API as a different package. It does not affect how netstandard is defined. Actually, the exact opposite is needed. We need to control how the netstandard implementation works on WASM target. There was discussion above where I suggested having more fine-grained control by defining Mono specific TFM so the netstandard packages could have in theory multiple WASM backends support, similar to coreclr/mono support but it looks like folks are in favour of single TFM.

jeromelaban · 2018-05-28T13:15:21Z

Sure, it's in a different package, but what's the TFM for this one? If wasm replicates the platform vs runtime ambiguity for Xamarin.ios and MonoAndroid, this is still compatibility issue regarding the Platform/BCL/Runtime version matrix.

wasm1.0 is a platform, and if the definition stays this way, it will implicitly mean wasm1.0 running on mono runtime because of internal calls dependencies. What if .NET core happens to support wasm as well ?

gulbanana · 2018-08-01T07:57:48Z

any progress on choosing a tfm name? as a library developer, i cannot support blazor until cross-targeting is available. the runtime environment is too different (no threads etc)

kzu · 2018-08-17T20:44:32Z

Would love to see this merged. I don't think there are outstanding issues, are there?

rohit21agrawal · 2018-08-17T22:45:32Z

the test failures on this PR are an issue for now, can @mhutch also rebase and push so we can validate against the latest dev branch?

mhutch · 2018-08-29T17:39:48Z

@rohit21agrawal rebased and pushed

mhutch · 2018-09-06T17:53:23Z

@rohit21agrawal looks like it failed due to the VSTS outage. Can we re-run it?

mhutch · 2018-09-20T17:26:10Z

It doesn't look like the failing tests are related to these changes. What can I do to move this along?

rohit21agrawal · 2018-09-20T17:44:45Z

the mac test failures are definitely related: https://devdiv.visualstudio.com/DevDiv/NuGet/_TestManagement/Runs?runId=2303373&_a=resultQueryEditor

mhutch · 2018-09-20T18:01:57Z

Sorry, didn't see those among all the random failures. Fixed!

rohit21agrawal · 2018-09-20T22:03:42Z

@mhutch CompatibilityListProvider tests are still failing on linux/mac/windows . You can ignore the functional test failures related to UwpBlankApp and Apex Test Failures

mhutch · 2018-09-24T19:24:50Z

ok, i think i fixed it.

mhutch · 2018-10-03T18:14:59Z

I have some packages that need to use this TFM :/

This is a higher level decision than I can make.

jainaashish · 2018-10-05T04:21:31Z

@mhutch Without understanding the background and proper scenario for this PR and analyzing alternate means to achieve it, we won't be able to proceed. So I'd suggest to set some time with @rrelyea to discuss and proceed with the PR.

jainaashish · 2018-12-06T17:16:41Z

There is no point in keeping this PR open at this time, until this has been discussed and finalized. So I'm closing this PR for now.

jeromelaban · 2018-12-06T17:17:34Z

@jainaashish is there a opened issue for discussing this ?

jainaashish · 2018-12-06T17:19:51Z

Not that I see any.. @mhutch can you open a workitem with all the details?

gulbanana · 2018-12-07T05:06:57Z

The lack of a tfm other than netstandard is still blocking me from porting libraries to Blazor.

weitzhandler · 2019-06-04T12:48:36Z

Ping.
This issue is blocking authors of .NET Standard frameworks to have wasm-specific ports. Can you please dedicate a TFM?
Could this issue be reopened?

@jainaashish have you had the chance to discuss this with @rrelyea?

jainaashish · 2019-06-04T16:52:00Z

@nkolev92 @anangaur

nkolev92 · 2019-06-04T18:16:54Z

@weitzhandler
These are decisions that are going to be made with other TFM stakeholders (not unilaterally by NuGet)
Please continue the discussion on the following issue: NuGet/Home#8186

weitzhandler · 2019-06-05T15:02:21Z

@nkolev92 I wish there was WebAssembly even as a general TFM temporarily, or any other immediate solution. Right now, NuGet and wasm don't work well together, can't build platform wasm projects with NuGet.
This is like a blocking issue.

nkolev92 · 2019-06-05T16:44:32Z

@weitzhandler

TFM changes are never temporary though.

If/when a new tfm is added, the scenario should be well understood and in conformance to where we think the eco-system needs to move, not as a workaround.

Regardless, expect updates on NuGet/Home#8186.

weitzhandler · 2019-06-05T21:45:19Z

Then a general wasm should be added permanently, then when we're ready, all the various dialects.

nkolev92 · 2019-06-05T22:16:49Z

I think the argument on the other issue is that we should not keep adding different dialects through additional frameworks.
Having too many frameworks was not a great experience in the past and we're trying to avoid it here.

The folks on that thread(Immo, Rich) have better context and know more about this topic than I ever will so I will defer to them. :)

mhutch mentioned this pull request Apr 12, 2018

Add WebAssembly framework moniker to NuGet mono/mono#7839

Open

rohit21agrawal added the Approved for CI label Apr 13, 2018

joelverhagen reviewed Apr 13, 2018

View reviewed changes

joelverhagen previously requested changes Apr 13, 2018

View reviewed changes

danroth27 mentioned this pull request May 11, 2018

[SLE] NRE when using Json.NET mono/mono#7852

Closed

jeromelaban mentioned this pull request May 26, 2018

WASM Platform must not target netstandard2.0 unoplatform/uno#14

Closed

jeromelaban mentioned this pull request Jun 19, 2018

Migrate to Wasm TFM when available from Nuget unoplatform/uno#51

Closed

jeromelaban mentioned this pull request Jul 5, 2018

Installing the package on an Android, iOS or UWP project should not break the build unoplatform/Uno.Wasm.Bootstrap#13

Closed

mhutch force-pushed the wasm-monoue-tfms branch from ab9d75a to 387b84b Compare August 29, 2018 16:37

rohit21agrawal added Approved for CI and removed Approved for CI labels Sep 4, 2018

mhutch force-pushed the wasm-monoue-tfms branch from 387b84b to 4a3bb31 Compare September 20, 2018 18:01

rohit21agrawal added Approved for CI and removed Approved for CI labels Sep 20, 2018

TFM mappings for WebAssembly and MonoUE

2e71098

mhutch force-pushed the wasm-monoue-tfms branch from 4a3bb31 to 2e71098 Compare September 22, 2018 01:44

rohit21agrawal added Approved for CI and removed Approved for CI labels Sep 24, 2018

rohit21agrawal requested review from jainaashish, nkolev92 and PatoBeltran September 24, 2018 20:46

jeromelaban mentioned this pull request Sep 27, 2018

Update nuget package to use WebAssembly TFM unoplatform/Uno.SQLitePCLRaw.Wasm#1

Closed

jainaashish closed this Dec 6, 2018

jeromelaban mentioned this pull request Feb 23, 2019

.NET Standard for WebAssembly dotnet/standard#1073

Closed

jeromelaban mentioned this pull request Jun 4, 2019

WebAssembly TFM support NuGet/Home#8186

Open

TFM mappings for WebAssembly and MonoUE #2159

TFM mappings for WebAssembly and MonoUE #2159

Conversation

mhutch commented Apr 12, 2018

rohit21agrawal commented Apr 13, 2018

joelverhagen Apr 13, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

terrajobst Oct 3, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joelverhagen left a comment

Choose a reason for hiding this comment

rohit21agrawal commented Apr 23, 2018

mhutch commented Apr 23, 2018

danroth27 commented May 11, 2018

danroth27 commented May 17, 2018

terrajobst commented May 17, 2018

marek-safar commented May 18, 2018

jeromelaban commented May 26, 2018

marek-safar commented May 28, 2018

jeromelaban commented May 28, 2018

gulbanana commented Aug 1, 2018

kzu commented Aug 17, 2018

rohit21agrawal commented Aug 17, 2018

mhutch commented Aug 29, 2018

mhutch commented Sep 6, 2018

mhutch commented Sep 20, 2018

rohit21agrawal commented Sep 20, 2018

mhutch commented Sep 20, 2018

rohit21agrawal commented Sep 20, 2018

mhutch commented Sep 24, 2018

mhutch commented Oct 3, 2018

jainaashish commented Oct 5, 2018

jainaashish commented Dec 6, 2018

jeromelaban commented Dec 6, 2018

jainaashish commented Dec 6, 2018

gulbanana commented Dec 7, 2018

weitzhandler commented Jun 4, 2019

jainaashish commented Jun 4, 2019

nkolev92 commented Jun 4, 2019

weitzhandler commented Jun 5, 2019

nkolev92 commented Jun 5, 2019

weitzhandler commented Jun 5, 2019

nkolev92 commented Jun 5, 2019 • edited Loading

joelverhagen Apr 13, 2018 •

edited

Loading

terrajobst Oct 3, 2018 •

edited

Loading

nkolev92 commented Jun 5, 2019 •

edited

Loading