Method enabled by __WASM__ in a cross runtime library for WASM isn't getting picked up in a WASM project

[roxk]

Steps to reproduce:

1. Create a new cross runtime library as documented here
2. In the generated WASM project, add a method surrounded by __WASM__.
3. Create a new uno WASM project and consume the library as nuget
4. Observe the method added in (2) isn't available.

[ivanjx]

please post your csproj files

[jeromelaban]

Indeed, it will be best if you post a sample repro project which shows what you're trying to do. Thanks!

[roxk]

I think my repro steps are quite clear, did you try it out? Anyways, I can create a minimal repro.

[FrozDark]

We need your repro sample

[roxk]

https://github.com/roxk/UnoCrossRuntimeWasmNotWorking

Here you are, the readme contains more info. Thanks!

[ivanjx]

try to add __WASM__ to your ConsumingApp.Wasm.csproj's DefineConstants

[jeromelaban]

This is an expected behavior. Cross-runtime libraries are only exposing what's in the "reference" API (CrossRuntimeLib/CrossRuntimeLib.csproj in your solution). This means that any project referencing this nuget package will not get access to those platform specific APIs (Skia or Wasm).

One way to handle this is to do something like this:

public void WasmOnlyMethod()
{
#if __WASM__
   // wasm specific code
#else
   throw new PlatformNotSupportedException();
#endif
}

[roxk]

This is not suitable for my use case as the WasmOnlyMethod needs parameter and that parameter is a uno only type.

Other cross-target libraries do not have this limitation and can add whatever method + types however they like in MonoAndroid or iOS. For example, adding a method that accepts Context in android and UIApplication in iOS. Why would uno have this limitation? What other solutions do I have now? This is library-breaking.

[jeromelaban]

The technique to handle this scenarion is with two packages, where those packages are built in the same solution.

For instance, you can make cross-runtime PackageA (your current package), and a second WebAssembly-only package named PackageA.WebAssembly. In that platform specific package, you can use WebAssembly-specific features that can be exposed to WebAssembly heads. You can create extension methods, or other helpers to get access to platform specific features, with platform specific types.

Uno uses this technique with the Uno.UI.Runtime.WebAssembly to expose WebAssembly only features to WebAssembly apps, like HtmlElementAttribute.

For the reason this is needed, the problem here is that Skia and WebAssembly are using the same TargetFramework, and there's no way for current .NET tooling, in a single package, to discriminate like you would with iOS (net6.0-ios), Android (net6.0-android), MacCatalyst, Windows, etc... which all have their own TargetFrameworkIdentifier.

This is a .NET and NuGet limitation, but also a feature which is also known as "bait and switch" materialized as RuntimeIdentifier switching.

[roxk]

In my case I need the WASM method to be part of a partial class and thus having the method defined in another package doesn't work. Extension method doesn't work as the method I'm trying to define is a constructor.

This situation is a bit like how I needed to access the UIElement(string) ctor defined in UIElement.wasm.cs but it isn't available in a WASM project. Same issue, manifested in two difference scenarios.

For the reason this is needed

I thought there was some build time logic employed by uno to pick up the WASM binary at build time but maybe this is not feasible. Thanks.

Uno itself just works, but TBF this library/multi-targeting situation isn't great. Sounds like a good reason to propose a wasm TFM, or dotnet will need a more sophisticated/flexible mechanism to pick binary.

In the mean time, I will bite the bullet and make a "reference API" accepting an object, and inside the method try to cast the object to the correct type (in a __WASM__ guard).

[jeromelaban]

In the meantime, I will bite the bullet and make a "reference API" accepting an object, and inside the method try to cast the object to the correct type (in a __WASM__ guard).

If you need to provide an instance through the constructor, in the MyControl.WebAssembly package, create a helper class with a method that will new your class with the proper parameters MyControl MyControlHelper.Create(MyWasmCustomParameter) { ... }.

I thought there was some build time logic employed by uno to pick up the WASM binary at build time but maybe this is not feasible. Thanks.

It's not the current behavior as while it may work for heads, it will not work for libraries which only have one target framework available (netstandard2.0) which covers both Wasm and Skia based targets.

Uno itself just works, but TBF this library/multi-targeting situation isn't great. Sounds like a good reason to propose a wasm TFM, or dotnet will need a more sophisticated/flexible mechanism to pick binary.

It may be, yet WebAssembly is not just one environment (the browser) and locking onto one particular environment at this time is premature, as there's already newer environment appearing like wasi. For now, a common API with RID replacements is good enough, and is forward compatible.

[roxk]

@jeromelaban I'm getting a namespace not resolved error. In the updated minimal repro which now compiles, I'm getting .nuget\packages\uno.wasm.bootstrap\3.3.1\build\Uno.Wasm.Bootstrap.targets(175,5): error : [00:00:00.5895220] Unhandled exception. System.Exception: Could not resolve CrossRuntimeLib in the cosuming app project. Anything I missed?

(The doc certainly could use some update)

[jeromelaban]

If you can provide the whole build log, it'll be easier to troubleshoot.

[roxk]

@jeromelaban The problem was caused by dependency indeed, and I have fixed that (removing any package reference related to XamarinEssentials in WASM project and move it to the netstandard project fixed it), and the wasm project can now consume the wasm-aware cross runtime lib and compiles. I'm now facing another issue: At launch, console log shows $namespace.GlobalStaticResources couldn't be found. I could reproduce it in the same minimal repro, please take a look.

Enclosed is a screenshot of the content of the two binaries of the lib, as shown via dotpeek:

You can see GlobalStaticResources is indeed not present in the WASM binary, whereas it's present in the ordinary netstandard binary.

Thanks!

[roxk]

Since nuget isn't working, I'm trying to copy all source of the library (all code is in a shared project anyways) to the consuming app to consuming it. Now the same GlobalStaticResources missing error is thrown on Uno.UI.Wasm by Uno.Xamarin.Essentials...If it helps, my project is a Uno UWP -> WASM project, not a uno xamarin.form -> WASM project. Version of Uno.Xamarin.Essentials is latest, i.e. 1.4.1-uno.13.

[jeromelaban]

Thanks for the update. This likely means that the Uno.Xamarin.Essentials package is having an issue with the runtime replacement and the end of the build, which is likely because it was not updated to support this feature.

We have not pursued updating Uno.Xamarin.Essentials because most developers are using the WinRT APIs directly, instead of going through Xamarin.Essentials.

[roxk]

This breaks any library which was using xamarin essentials though. It's fine, I can remove the reference to xamarin essential for when __WASM__ is present in the library, but it'd be great if uno can update that forked package. Xamarin.Essentials won't get any new features anyways.