Sharing platform specific code - FrameworkElement

[bartekwojcik]

I'm studying Uno platform, and I would like to write my platform specific code in separate assemblies without using #if statements. I googled this link where they suggest using partial classes. Works fine but then I'd like to swap FrameworkElement depending on a platform. I followed this tutorial and this one and got this code for WASM head that is located in .Shared project:

[HtmlElement("input")] // Flatpickr requires an <input> HTML element
public partial class FlatpickrView : FrameworkElement
{
// *************************
// * Dependency Properties *
// *************************

public static readonly DependencyProperty SelectedDateTimeProperty = DependencyProperty.Register(
    "SelectedDateTime", typeof(DateTimeOffset?), typeof(FlatpickrView), new PropertyMetadata(default(DateTimeOffset?)));

public DateTimeOffset? SelectedDateTime
{
    get => (DateTimeOffset)GetValue(SelectedDateTimeProperty);
    set => SetValue(SelectedDateTimeProperty, value);
}
//rest of the properties
}

To keep this code explicitly just for WASM I moved this file to .WASM project and added empty stub in .Shared project:

namespace FlatpickrDemo
{
    public partial class FlatpickrView : FrameworkElement
    {
    }
}

But the result is that when I'm starting project with WASM head no JavaScript is executed and FlatpickrView is not used.
How do I effectively swap Control or Elements depending on a platform while keeping code in its respective head?

[jeromelaban]

This article may help.

[bartekwojcik]

Thank you, I'll test it asap!

[bartekwojcik]

Let's assume we are targeting 3 platforms, Android, Windows and WASM.
Code that I want to share only with WASM, could be in a project called, let's say, WasmLibrary.
Code that I want to share with Windows and Android but not with WASN would have to be duplicated in similar projects like AndroidLibrary and WindowsLibrary or have a single project called WindowsAndAndroidLibrary.
Then If I want to keep something only for WASM and Windows then again, I have to duplicate code in WASMLibrary and WindowsLibrary or create yet another project like WASMAndWindowsLibrary.

This creates a proliferation of projects and a ticking bomb that sooner or later will create problems.

If I decide to keep everything in Shared project, then I have to keep using ugly and hard to maintain #if #endif and keep having intellisense telling me that there are errors because such and such library is not available for this and that platform. I can keep switching visual studio context to different heads but that's confusing as well.

What am I missing?

[jeromelaban]

I'm not sure to follow your issue. Can you provide a sample that demonstrates what you're trying to achieve?

[bartekwojcik]

Thanks for your time, I'll prepare a sample soon.

[ToddGlodek]

Maybe what @bartekwojcik is getting at is the following :

1. There is no "Target Framework" option specifically for WASM when it comes to the 'Uno Platform Library" / Cross-platform library that you can create as a new project from the project templates. Developers familiar with Xamarin/Maui will (initially) expect this to be the case.
2. In my experience, the " #if _ _ WASM _ _ " compiler directive used to generate WASM "platform specific code" is not available (using intellesense anyway) when you use the 'Uno Platform Library" from the 'Create Project' window in Visual Studio

As discussed in @MartinZikmund's StackOverflow post, the documentation provided for creating a new cross platform library using the command line tool DOES show a different way to create one of these libraries.

Uno Platform Blank Cross-Runtime library
This template can be used to create a blank cross-runtime library, when platform specific code needs to be created for Skia and WebAssembly.
dotnet new unolib-crossruntime -o MyCrossRuntimeLibrary

This approach DOES create what looks like a specific WASM target framework option. Plus, the " #if _ _ WASM _ _ " is available in intellisense with this approach.

However, the cross-platform library created by the command line tool ( e.g. 'MyCrossRuntimeLibrary.Wasm' ) uses the obsolete netstandard2.0 as a target framework ( even though it uses the lateset 4.5.9 Uno.UI libs ). This makaes is look old and feel obsolete & probably not the right thing to be doing.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <IsPackable>false</IsPackable>
    <RootNamespace>MyCrossRuntimeLibrary</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Uno.UI.Runtime.WebAssembly" Version="4.5.9" />
  </ItemGroup>
</Project>

@jeromelaban - I'm not sure what happens if you replace "netstandard2.0" with "net7" (so you can use the latest C# features? Will that still work ??

[jeromelaban]

@ToddGlodek you can use net7.0 instead of (or in addition to) netstandard2.0 and it will work as well. This will force your library consumers to use net7.0 as a result, though.

[ToddGlodek]

Thanks for the guidance. Unfortunately, it looks like every Uno Platform project team will need someone with a PHD in "Visual Studio Build File Configuration & Customization".

[jeromelaban]

We're improving our guidance and templates as we go, this one definitely needs update.

We're dependent on what the .NET ecosystem is able to provide us, unfortunately, and these are edge cases that the .NET SDK does not provide by default and causes some friction.