[Feature Request] Add support for win-arm64

[PejmanNik]

Is your feature request related to a problem? Please describe.

Windows on ARM is becoming increasingly popular, and local machines with this CPU architecture are becoming more common. Not supporting such a major architecture could be a significant drawback for the library.

Describe the solution you'd like

Adding support for win-arm64

[cretz]

None of our core-based SDKs (TypeScript, Python, .NET, or Ruby) ship a prebuilt Windows ARM build. You should be able to manually build it, but unfortunately adding this by default to the NuGet package makes it bigger by several megs for everyone (I think it's ~8MB for each additional platform we support). We also don't prebuild for other arguably more popular OS/arch's too like Windows 32-bit (popular with many of our .NET users), and Linux MUSL (which is quite popular IIRC since Alpine is the common .NET container base). Ref https://github.com/temporalio/sdk-dotnet?tab=readme-ov-file#built-in-native-shared-library.

Is it possible to build the package yourself for this architecture? We may be able to consider new NuGet packages who simply provide this DLL and nothing more, but so far we have encouraged all users not using OS/arch's we prebuild for to build the package themselves.

[PejmanNik]

Thank you. Yes, building the package locally is not an issue, but it makes it impossible to sell it as an enterprise solution when team members cannot easily run the project.

It seems this is more related to a NuGet limitation. What do you think about moving the download process to runtime? This should improve restore times, as it wouldn’t need to download the DLLs for all architectures

[cretz]

What do you think about moving the download process to runtime?

We definitely would like to use the traditional package management process. Some users may not be ok with a library downloading DLLs and running them at runtime. If your users are ok with this, you can put the prebuilt DLL somewhere and download it to the right spot before loading the DLL.

But again, we may be able to put this in separate NuGet packages, but we have to have some discussions about effort to provide/maintain official packages for these OS/arch setups that we do not in any SDK today. It does require a good amount of CI efforts.

[PejmanNik]

That makes sense. Thank you for your response!