Requirements

Target framework reach, storage options, and the memory-metric fallback behavior by host.

  • The package targets netstandard2.0 for the broadest possible reach on the consuming app's side: .NET Core 2.0+, .NET 5+, or classic .NET Framework 4.6.1+ can all reference it (ConnectionStringName's classic web.config support exists for exactly that last case).
  • ASP.NET Core only for the core package — UseNafasDashboard requires IApplicationBuilder. For WinForms/WPF/console apps, see Desktop and other non-ASP.NET Core apps instead.
  • SQLite (zero setup) or SQL Server 2016+ for storage.

The memory-usage metric fallback

memoryUsage (one of several resource metrics — logs, traces, CPU usage, and alerting are all unaffected either way) is read differently depending on the host, in this order:

  1. .NET Core 3.0+ / .NET 5+ (the common case) — GC.GetGCMemoryInfo(), which is container-aware: it reflects a cgroup or Docker memory limit when one is set, not just physical host RAM.
  2. Classic .NET Framework 4.6.1+, or .NET Core 2.x, on Windows — falls back to the Win32 GlobalMemoryStatusEx API (the same one .NET Framework apps have always used for this, no managed equivalent exists there). This reports whole-machine physical memory, not container/Job-Object-aware, so a process capped by a Job Object memory limit will under-report here.
  3. Any non-Windows host without GC.GetGCMemoryInfo() (practically: .NET Core 2.x on Linux/macOS) — reports 0. This path is explicitly gated to Windows only, so a Linux container never attempts a kernel32.dll call in the first place.

Classic .NET Framework + SQLite: set an explicit PlatformTarget

netstandard2.0 compatibility means .NET Framework can reference this package, but the SQLite native driver still needs to know which architecture to load. On .NET Core/.NET 5+, the runtime's own RID-graph resolves this automatically regardless of how the project was built; on classic .NET Framework there's no such mechanism, so an AnyCPU build can copy a native e_sqlite3.dll that doesn't match the process's actual bitness at run time, failing with Library e_sqlite3 not found / %1 is not a valid Win32 application.

Set <PlatformTarget>x64</PlatformTarget> (or x86, matching your deployment) and <Prefer32Bit>false</Prefer32Bit> explicitly in the consuming .csproj to fix it — verified against a real net48 console host in Nafas.Observability.Server.NetFrameworkSample. SQL Server storage isn't affected (no native driver to resolve this way).