net8.0 / net10.0 Multi-Target Support

[squarebananas]

I've managed to get net8.0/net10.0 working on my branch for BlazorGL.

However there appears to be some issues with net10.0 release candidate 2 which prevents web publishing from working. There is also unexpected pausing of browser execution (requiring manually resuming in the browser dev tools).

So at this point it doesn't make sense pushing these changes until net10.0 is properly released and can be tested in full.

Here are some notes so far though on getting net10.0 to work with BlazorGL.

Adds net8.0 / net10.0 RC2 multi-target support

squarebananas/Gumknix@63ecf4b
squarebananas@806d1c6
squarebananas/Wasm@c5d1486

Currently net10.0 can only be used with VS2026. This should change after release with VS2022 17.16 apparently. Adding net8.0;net10.0 to any library currently breaks VS2022, even if the project using the library is only targeting net8.0.

It seems using [MSBuild]::VersionGreaterThanOrEquals can workaround this issue though. Doing this allows a net8.0 project to open in VS2022, and for it also to be switched to net10.0 and opened with VS2026 (after bin/obj cleaning).

Previously net9.0 required csproj property overrides for fingerprinting of web assets to be disabled. This no longer seems to be the case, although it would be useful to return to this in the future (to force reload of changed assets without manually clearing browser cache).

Reimplements JSObject.ReadString after Blazor removed BINDING.conv_string

squarebananas/Wasm@5d9a86b

BINDING is no longer available in Blazor net10.0. It seems a string length appears 8 bytes offset from the pointer location and the UTF-16 characters at 12 bytes offset. Currently it seems to work but might need more testing.

Re-adds globalThis.Module after Blazor net10.0 removal

squarebananas/Gumknix@21a859a

Module is no longer available in Blazor net10.0. Currently this fix just adds it back to the same object unless it already exists (so it won't do anything with net8.0 where it will exist). I think I read this is because Module is a fairly generic name and this may cause conflicts with some js libraries. Perhaps in the future this could be changed across nkast.Wasm to nkModule or something?

Re-adds Blazor.platform.getArrayLength after Blazor net10.0 removal

squarebananas/Gumknix@628f64c

Blazor.platform.getArrayLength is no longer available in Blazor net10.0. Like above this fix just adds it back to the same object unless it already exists. As the calling methods to this will likely also call getArrayEntryPtr, it's possible that this will be called twice now (that may have been happening before internally anyway). I guess the array length could be passed with the array object in all nkast.Wasm C# methods, but that's quite a large change and probably isn't necessary.

Png.ReverseByteArray net10.0 compiler workaround

squarebananas@cc41cd6

For some reason VS2026 will claim byteArray.Reverse.ToArray isn't available for net8.0. It seems to resolve to MemoryExtensions.Reverse instead of IEnumerable.Reverse. VS2026 doesn't have a problem when using net10.0 though, and obviously VS2022 doesn't have a problem with net8.0 either. It's just VS2026 with net8.0. For now explicitly using Enumerable.Reverse(byteArray).ToArray(); resolves this, although it really shouldn't be necessary to do this.

I'll return to this once net10.0 is released in full, although I won't be around much next month, so it might be after that.

[squarebananas]

I'll return to this once net10.0 is released in full

The previous issues (with web publishing and unexpected debug pausing) seem to be resolved now. Also VS2022 seems to skip net10.0 builds correctly if both VS2022 & VS2026 are installed, but I'm not sure what would happen without VS2026 now.

So I would make some PRs for these commits, however I'm unsure how that would effect building with only VS2022 installed (which failed before).

[squarebananas]

Adding net8.0;net10.0 to any library currently breaks VS2022, even if the project using the library is only targeting net8.0.

So I would make some PRs for these commits, however I'm unsure how that would effect building with only VS2022 installed

I've tried this on a VM with only VS2022 installed, and it still fails to build.

Interestingly it seems VS2022 community edition is no longer featured / linked on the Visual Studio website now, with only VS2026 shown instead: https://visualstudio.microsoft.com/downloads/

So maybe it makes more sense now to deprecate using VS2022 for building Kni from source. Even if someone did want to in the future, it would be relatively simple for them to find/replace net8.0;net10.0 with just net8.0 in any case.

In the meantime, I have added a nkast.Wasm PR for "Adds nkJSObject.DotNetVersionFixups for dotnet 10.0" so that manually adding net10.0 when building from source will work: nkast/Wasm#19