Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#479 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
csharp, node.js
Ambito
backend, devtools

Direzione di ricerca

Inizia con il nad-repro.zip allegato, in particolare repro.js, probe e probe-console, ed esegui i casi native console e node-api-dotnet su Windows. Leggi il comportamento dell’hosting relativo all’isolamento di AssemblyLoadContext e confrontalo con la limitazione di System.Management a cui si fa riferimento. Il lavoro è completato quando si determina se il livello di hosting può risolvere il problema; in caso contrario, documenta la limitazione nella README.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
C#
Stelle
783
Fork
80
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/node-api-dotnet

Tutte le issue di microsoft/node-api-dotnet

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.