GeezerVison

Brings class extension, threading and native C# code on Windows in line with what the iOS and Android runtimes offer, and adds a runtime test app like theirs.

Class extension

JS can extend .NET classes and unsealed WinRT/WinUI classes with ES2015 class, Class.extend(), @NativeClass, TypeScript's ES5 output (__extends / _super.call(this)) and Object.extend({ interfaces }). When native code calls an overridden member, it reaches the JS override; for example, XAML calls MeasureOverride on a JS Panel subclass.

Previously:

• override arguments were lost;
• super and constructor arguments didn't work, and neither did instanceof;
• this wasn't the JS object;
• class X extends <WinUI class> produced a plain base object.

What changed:

• Base calls and constructors: super.X() / this.super.X() call the base implementation through non-virtual __ns_base_X methods the bridge emits. super(...) arguments select the base constructor, including protected ones.
• Members: abstract members, protected members and property accessors can be overridden.
• Identity: instanceof works for the subclass and its native bases. JS fields are visible to native calls. Native code handing an instance back returns the same JS object.
• Interfaces: new Interface({...}) and @Interfaces implement interfaces.
• Lifetime: the dispatcher holds the JS object weakly, and the bridge unpins it when the managed object is collected. If native code calls into an instance whose JS object was collected, a new JS object is created for it (Android markingMode: none semantics). WinRT UI subclasses stay alive while in a live XAML tree.
• sbg removed from the template: sbg-generated proxies are no longer built or shipped (template csproj and template/build.ps1), because the bridge emits the types at runtime.

Threading

• Background callbacks: WinRT delegates, .NET delegates and events, overridden members and Task continuations that fire on a background thread now run on the JS thread that created them while the caller waits: the UI thread, or (classic) the worker that created them. Return values and exceptions flow back. Before, they were dropped (classic) or made napi calls off-thread (napi). This applies to both engines. A callback whose worker has terminated is refused (a JsException for callbacks that return a value).
• Worker messages: messages a worker posts on its own (from a timer or a callback) reach the main thread's onmessage. Before, they were only picked up while the main thread was inside worker.postMessage.
• Tasks: .NET methods returning Task now return an awaitable instead of blocking the UI thread.
• Static events: static WinRT events (CompositionTarget.Rendering = fn) now work on class constructors. Adding, removing and reparenting XAML elements from Rendering/LayoutUpdated/SizeChanged handlers is covered by tests; the 0xC000027B crash couldn't be reproduced.

C# in apps and plugins

• Namespaces as globals: root namespaces of the app's own assembly and of plugin and NuGet assemblies are globals. C# files under App_Resources/Windows (e.g. src/) or in a plugin's platforms/windows work by namespace with no registerNamespace.
• Marshaling: JS functions can be passed where a delegate is expected (their return values are used), plain objects where structs are expected, and enums. Overloads with the same parameter count are picked by type.
• Object values: the classic engine unboxes boxed primitives (element.Tag = 'a' reads back 'a'; PropertySet values), as the napi engines already did. Before, they read back as an opaque wrapper.
• System global: System stays the .NET namespace when @nativescript/core assigns its SystemJS shim. Before, System.IO etc. were unreachable in core apps.

Other fixes

• V8 platform tasks: the classic engine now pumps V8 platform tasks and clears kept objects after the per-frame drain. Without it, FinalizationRegistry never ran, so .NET handles of collected proxies were never released, and WeakRef targets never died.
• Unpackaged apps: the template runs unpackaged (WindowsPackageType=None) instead of crashing on ApplicationData.
• Template output: C# sources under App_Resources aren't copied to the output.
• require: a top-level relative require() now works when the entry isn't bundle.js (both engines).
• napi instanceof: class prototypes chain to their WinRT base class's prototype, so instanceof works for base classes.
• napi delegate helper: added a public make_napi_void_delegate, so the windows-napi test helper builds again.

Tests

• test-app/: a Jasmine-style suite inside a WinUI app built from template/framework (the way ns prepare does), with C# fixtures in App_Resources/Windows/src and a local plugin that ships C# sources. Run it with pwsh test-app/run.ps1, or -EngineDll packages/windows-v8/target/release/windows_v8.dll for a napi engine. It covers C# sources, .NET and WinRT extension, threading (including workers), Object unboxing, layout mutation and lifetime.
• dotnet-bridge-tests/JsSubclassTests.cs: bridge-side tests; the existing tests are updated for the per-argument dispatch payload.

I also checked end to end with the desktop starter template: the C# file in App_Resources/Windows/src compiled through the CLI, and a JS subclass override was called from C#.

Behaviour changes

• .NET Task results are awaitables instead of synchronously awaited values.
• JS exceptions in callbacks that return a value now surface to the .NET caller as JsException. Void callbacks still only report them.
• A JS subclass of a class with no parameterless constructor needs super(...) arguments.

Related: CLI NativeScript/nativescript-cli feat/windows-csharp-sources, docs NativeScript/docs docs/windows-extending-threading-csharp.