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

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

Start with the attached nad-repro.zip, especially repro.js, probe, and probe-console, and run the native console and node-api-dotnet cases on Windows. Read the hosting behavior around AssemblyLoadContext isolation and compare it with the referenced System.Management limitation. Done means determining whether the hosting layer can address the failure; if not, document the limitation in the README.