Update Windows dll metadata to add UWP platform support

[BallistiX09]

WindowsStoreApps (UWP) platform support has been enabled on all of the Windows dll files. No editor or standalone support enabled on the ARM64 dll currently since this requires Unity 6, which is still in preview and not fully released.

[gilzoide]

As far as I know, "Win" platform is the x86 version of Windows.
I don't think this is supposed to be enabled 🤔

[gilzoide]

I don't think this should be disabled. Even if it requires Unity 6, why not keep this configured so that people can try it out? I mean, if it doesn't work the way it is, we can fix later, but until we know that this doesn't work, just let it be. What do you think?

[gilzoide]

Same as before, "Win" being the x86 version of Windows, this should probably be disabled.

[gilzoide]

Hey @BallistiX09, thank you very much for adding UWP support to the DLLs =D

Already said this in the comments, but I think the ARM64 DLL should be kept configured, there is no point in disabling it even if it requires Unity 6. Maybe it just works the way it is. I haven't tested, but until someone does, we don't know if it is broken or not. Disabling this would actually make it harder for people to test it and report a broken build.

[BallistiX09]

Hey @BallistiX09, thank you very much for adding UWP support to the DLLs =D

Already said this in the comments, but I think the ARM64 DLL should be kept configured, there is no point in disabling it even if it requires Unity 6. Maybe it just works the way it is. I haven't tested, but until someone does, we don't know if it is broken or not. Disabling this would actually make it harder for people to test it and report a broken build.

No problem at all! I've actually set the ARM64 DLL up so that (as far as I know), it should automatically work with future versions like you've mentioned. When I mentioned disabling editor/standalone support, I just meant the CPU architectures, they're both enabled overall as options though, sorry!

The "Exclude Win" and "Standalone: Win" options are controlled by enabling/disabling Standalone as a platform option (allowing classic Windows builds along with UWP builds). Although I've enabled Standalone as a platform, I've disabled both the x86 and x64 CPU checkboxes, so it shouldn't try to use the ARM64 DLL on non-ARM CPUs. My thinking is that when upgrading to Unity 6, it'll automatically add the new ARM64 option to Standalone (since the platform is still enabled), while leaving the x86 and x64 CPUs disabled.

So currently, the ARM64 DLL is set up as:

- Any platform disabled
- Editor enabled, Windows OS, ARM64 CPU architecture (actually showing in-editor as Apple Silicon, but it's showing correctly in the meta file as ARM64)
- Standalone enabled, x86 and x64 CPU architectures disabled (in hopes ARM64 will automatically add down the line)
- WSAPlayer enabled, any SDK, ARM64 CPU architecture, any scripting backend, don't process disabled
- iOS/Android disabled

If you prefer, I could just go ahead and download the Unity 6 beta just now and set up the DLLs in there, I'm just not sure how that would affect backwards compatibility though (if at all).

[BallistiX09]

I ended up just downloading Unity 6 anyway to test how it handles the upgrade, and it looks like it selects ARM64 as the editor option correctly, but it defaults to enabling x64 as the Standalone CPU option if none are selected originally, so that wouldn't upgrade nicely.

I also noticed in the x86_64 DLL, it selects Any CPU for Standalone instead of x64 which was originally selected, which is strange (though that might not actually cause issues though). All of the non-Windows meta files seem to be fine after the upgrade though, so it's just those two with issues.

I tried taking those meta files from Unity 6 and adding them back into my Unity 2022 project, and it completely removes the platform settings entirely for those DLLs (possibly because serializedVersion is v3 instead of v2 on those files), so pushing those meta files would leave users on older Unity versions without platforms set up by default. Not too sure if you'd prefer to have standalone removed entirely from ARM64's DLL, just let me know though and I can get those updated and pushed!

[gilzoide]

Hey @BallistiX09, thank you for the test in Unity 6 and all the explanation.

I totally forgot about it, but I actually had setup the ARM64 DLL in Unity 2023.2, which already supports building for Windows ARM.

I'm on a macOS with Apple Silicon, and the inspector for it looks like this:

As you mentioned, for the "editor" it says that the architecture is "Apple silicon", but it's "ARM64" in the .meta file. I guess Unity will do the right thing there, avoiding this DLL on a x86_64 editor and using it on Unity 6 editor on ARM64.
The "Win" platform is changed by the "x86" checkbox in the standalone configurations, which is disabled here.

Until someone tries this in the Unity 6 editor on an ARM64 Windows machine, I think we shouldn't upgrade the serializedVersion. It's possible that it will work in Unity 6 the way it is, and people using Unity 2023.1+ will still be able to export projects with SQLite-net to Windows ARM.

The diff I'd expect there is just like the other ones, just the addition of the WSAPlayer entry.
What do you think?

[BallistiX09]

@gilzoide Sorry about the wait, got a little sidetracked on this! I've updated the ARM64 dll to remove the Windows standalone changes, so all that's been added is UWP support to match the X86 and X64 dlls. Hopefully that should be it all sorted!

[gilzoide]

Hey @BallistiX09. Don't worry about it, we are all busy with lots of things.
Thank you for the update! I think this is better, we have UWP support in all DLLs, the ARM likely works in Unity 2023.1+, success!
Thanks again for the upgrade, I really appreciate you taking some time to expand this package's support to other platforms.

Cheers \o/