Build cross-platform packages for supported OS+CPU matrix

[jasongin]

No description provided.

[vmoroz]

We implemented build of a cross platform packages for OSX.
Building on linux-arm64 and other ADO publish pipeline related tasks is tracked by #80.

[reidatlokblok]

Should this work currently on MacOS Arm64? We have been unsuccessful with loading the node-api-dotnet module:

with dotnet 6 installed we get: 0x80131621 failed to load managed host assembly
with dotnet 6 uninstalled and dotnet 8 installed we get - FrameworkMissingFailure
with both dotnet 6 and dotnet 8 installed we get same result as 1
No problem on x64 MacOS.

SDK's installed using MS installers.
DOTNET_ROOT environment variable set to /usr/local/share/dotnet
using latest npm package 0.4.16

[jasongin]

@reidatlokblok Sorry it is not yet tested on Mac arm64. We'd like to add that support soon.

[reidatlokblok]

I appreciate the quick response. We can get it to work if we pull source from origin/main and build on mac min m1. That so far seems to work but we have alot more testing to do. There may be an issue with the build for macos arm64 in your npm release.

[jasongin]

We can get it to work if we pull source from origin/main and build on mac min m1.

That's good to know. The Mac arm64 npm package is currently built on an Intel Mac machine. I think that's supposed to work (?) but there might be some misconfiguration with that build, as you say. We're trying to get a build/test pipeline set up for Mac arm64.

[jasongin]

So actually we do already have a macOS arm64 build agent in our Azure DevOps release pipeline. But I found a bug in the .NET install task that causes it to install x64 instead of arm64 build of .NET. Apparently the binary produced in that compatibility mode doesn't work on a real arm64 system.

[reidatlokblok]

Thanks for continuing to look into this. We did try swapping out the osx-arm64 folder in the release on npm with the one built on the m1/m2 and that did not work. We found that the dotnet assemblies in net6.0 folder if built on the m1/m2 work on the m1/m2 but no where else AND if we use the ones from npm they work everywhere except on the m1/m2. We are now looking at how those are built differently on m1/m2 vs other platforms.

[reidatlokblok]

In case it helps, if we build on m1/m2 and try on macos x64 this exception is thrown (but if we use the npm package it works fine):

Error: Failed to load managed host assembly. HRESULT: 0x80131621
at Microsoft.JavaScript.NodeApi.DotNetHost.NativeHost.CheckStatus(HostFxr.hostfxr_status, String) + 0x222
at Microsoft.JavaScript.NodeApi.DotNetHost.NativeHost.InitializeDotNetHost(Version, String, JSValue) + 0x32f
at Microsoft.JavaScript.NodeApi.DotNetHost.NativeHost.InitializeManagedHost(JSCallbackArgs args) + 0x710
at Microsoft.JavaScript.NodeApi.JSNativeApi.InvokeCallback[TDescriptor](JSNativeApi.Interop.napi_env, JSNativeApi.Interop.napi_callback_info, JSValueScopeType, Func`2) + 0x2ed
at initialize (/Users/rcarlisle/Downloads/dotnetjs/node_modules/node-api-dotnet/init.js:26:21)
at Object. (/Users/rcarlisle/Downloads/dotnetjs/node_modules/node-api-dotnet/index.js:2:18)
at Module._compile (node:internal/modules/cjs/loader:1275:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1329:10)
at Module.load (node:internal/modules/cjs/loader:1133:32)
at Module._load (node:internal/modules/cjs/loader:972:12)
at Module.require (node:internal/modules/cjs/loader:1157:19)
at require (node:internal/modules/helpers:119:18)
at Object. (/Users/rcarlisle/Downloads/dotnetjs/index.js:2:20)
at Module._compile (node:internal/modules/cjs/loader:1275:14)

and if we use the one from npm on the m1/m2 we get the following exception (but if we use the one we built on the m1/m2 it works):

Error: Failed to load managed host assembly. HRESULT: 0x80131621
at Microsoft.JavaScript.NodeApi.DotNetHost.NativeHost.CheckStatus(HostFxr.hostfxr_status, String) + 0x278
at Microsoft.JavaScript.NodeApi.DotNetHost.NativeHost.InitializeDotNetHost(Version, String, JSValue) + 0x30c
at Microsoft.JavaScript.NodeApi.DotNetHost.NativeHost.InitializeManagedHost(JSCallbackArgs args) + 0x6a8
at Microsoft.JavaScript.NodeApi.JSNativeApi.InvokeCallback[TDescriptor](JSNativeApi.Interop.napi_env, JSNativeApi.Interop.napi_callback_info, JSValueScopeType, Func`2) + 0x284
at initialize (/Users/m1/source/local/dotnetjs/node_modules/node-api-dotnet/init.js:26:21)
at Object. (/Users/m1/source/local/dotnetjs/node_modules/node-api-dotnet/index.js:2:18)
at Module._compile (node:internal/modules/cjs/loader:1376:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
at Module.load (node:internal/modules/cjs/loader:1207:32)
at Module._load (node:internal/modules/cjs/loader:1023:12)
at Module.require (node:internal/modules/cjs/loader:1235:19)
at require (node:internal/modules/helpers:176:18)
at Object. (/Users/m1/source/local/dotnetjs/index.js:2:20)
at Module._compile (node:internal/modules/cjs/loader:1376:14)

[reidatlokblok]

There was no difference in the code between what we built on the m1/m2 and what is released in npm (except for the source paths). The ProcessorArchitectures were different. On the npm build GetAssemblyName contains Amd64 (and the decompiled project file targeted Amd64) and our build on the m1/m2 GetAssemblyName contains 'none' (though the decompiled project was set to Arm64); we expected the files in the net6.0 and other dotnet directories to have a ProcessorArchitecture set to MSIL?

Could that explain why we saw the dll built on m1/m2 only worked on Arm64 MacOS and the one in npm worked everywhere else (that is Amd64 - we dont have an win-arm or lin-arm machines).