System.Management throws PlatformNotSupportedException under hosted CLR on Windows — breaks Hardware.Info, DeviceId.Windows.Wmi, etc.

Bắt đầu với nad-repro.zip được đính kèm, đặc biệt là repro.js, probe và probe-console, rồi chạy các trường hợp native console và node-api-dotnet trên Windows. Đọc cách lớp hosting hoạt động xung quanh việc cô lập AssemblyLoadContext và so sánh với giới hạn System.Management được tham chiếu. Công việc được xem là hoàn tất khi xác định được liệu lớp hosting có thể xử lý lỗi hay không; nếu không, hãy ghi lại giới hạn này trong README.

Summary

Any NuGet package that uses System.Management (WMI) fails with PlatformNotSupportedException when loaded through node-api-dotnet
on Windows, even though the same package works fine from a native .NET console on the same machine.

Confirmed against node-api-dotnet@0.9.21 pinned to both /net8.0 and /net10.0. WSL2 (Linux runtime, no WMI path) works normally.

Repro

Attached zip (nad-repro.zip, ~4 KB, 8 source files, no node_modules / DLLs):

nad-repro/
├── package.json node-api-dotnet@0.9.21 only
├── repro.js 18 lines of Node
├── probe/ Class library; only ref is Hardware.Info 101.0.0
└── probe-console/ net8.0 console exe — control case

Steps:

npm install
dotnet publish probe -c Release -f net8.0 -o native --no-self-contained

Baseline — works:

dotnet run --project probe-console -c Release -f net8.0

cpuCount=1 coreCount=16 error=(none)

node-api-dotnet — fails:

node repro.js

{

"cpuCount": 0,

"coreCount": 0,

"error": "PlatformNotSupportedException: System.Management currently is only supported for Windows desktop applications."

}

Stack:

System.Management.ManagementOptions..ctor()
System.Management.EnumerationOptions..ctor()
Hardware.Info.Windows.HardwareInfoRetrieval..ctor(Nullable)
Hardware.Info.HardwareInfo..ctor(Boolean, Nullable)

Environment

• Windows 11 23H2 (also Windows 10)
• .NET 10.0.202 SDK installed (project targets net8.0)
• node-api-dotnet 0.9.21
• Hardware.Info 101.0.0
• Node 22.x

What works / doesn't

Scenario	Result
Native .NET 8 console, same Probe.dll	✓ Works
node-api-dotnet/net8.0 on Windows	✗ PlatformNotSupportedException
node-api-dotnet/net10.0 on Windows (with .NET 10 runtime installed)	✗ Same exception
node-api-dotnet/net8.0 inside WSL2 Ubuntu (Linux runtime, no WMI)	✓ Works

Root cause (probably)

Likely a downstream symptom of dotnet/runtime#110604 (https://github.com/dotnet/runtime/issues/110604) — System.Management
rejects initialization in AssemblyLoadContext-isolated load scenarios. node-api-dotnet's hosting model puts the CLR into exactly
such a context. The workaround that issue proposes (explicit pre-load via LoadFromAssemblyPath) does not help here — pre-loading
System.Management.dll through dotnet.load() before the consumer DLL produces the same exception.

Impact

Every NuGet package that relies on System.Management on Windows is unusable via node-api-dotnet:

• Hardware.Info (CPU/motherboard/etc enumeration)
• DeviceId.Windows.Wmi
• Most machine-fingerprinting / license-binding libraries

The failure is silent: the exception happens inside a constructor that's typically wrapped in try/catch by consumers, so callers
receive zero-filled or empty results and produce wrong outputs (in our case: a downstream consumer reads Cpucount == 0 and concludes 'no CPUs detected,' even though the machine has 16 physical cores.).

Is this fixable at the node-api-dotnet hosting layer, or is the
PlatformNotSupportedException strictly an upstream System.Management
limitation that node-api-dotnet has no leverage over?

If it is upstream-only, would it be worth documenting this as a known
limitation in the README so the next person doesn't have to discover it
the hard way? Happy to contribute the docs PR.

Reproducer is attached as nad-repro.zip — runs in under a minute on any
Windows machine with .NET 10 SDK + Node 22 installed.

nad-repro.zip