Entry-Point Runtime — .NET / C#
Heuristics the Stella Ops scanner uses to classify a container entry point as a .NET / C# application — framework-dependent, self-contained, or single-file — plus the evidence it attaches and the edge cases it guards against. For the shared detector contracts, scoring, and calibration, see the Runtime Detector Overview.
Signals to gather
- Framework-dependent:
dotnet <app.dll>invocation. - Adjacent
*.runtimeconfig.json(parsetfm, framework references, roll-forward). - Self-contained or single-file apps: ELF/PE with
DOTNET_BUNDLE,System.Private.CoreLib, orcoreclrmarkers. - ASP.NET hints:
ASPNETCORE_URLS,appsettings.json, presence ofwwwroot. - Windows builds: PE with CLI header (managed assembly) or native host embedding a bundle.
Implementation notes
- Resolve DLL paths relative to the working directory after env expansion.
- When
dotnetis invoked without a DLL, treat as low-confidence and record evidence. - For single-file executables, read the first few MB looking for bundle markers rather than full PE/ELF parsing.
- Capture runtimeconfig metadata when available; store TFM in
LanguageHit.MainModule. - Treat
dotnet execwrappers the same asdotnet <dll>.
Evidence & scoring
- Large confidence boost when both host (
dotnet) and DLL artefact are present. - Add evidence for runtimeconfig parsing (
"runtimeconfig TFM=net10.0"), bundle markers, or ASP.NET env vars. - Penalise detections lacking artefact confirmation.
Edge cases
- Native AOT (
dotnet publish -p:PublishAot=true) emits native binaries without managed markers — these should fall back to the C / C++ detector. - PowerShell-launched apps: ShellFlow should rewrite the command before the detector runs.
- Side-by-side deployment where multiple DLLs exist — prefer the one passed to
dotnetor specified viaDOTNET_STARTUP_HOOKS.
Related
- Runtime Detector Overview — shared contracts, scoring, calibration.
- Entry-Point Runtime — C / C++ — fallback for Native AOT binaries.
- .NET analyzer — SBOM component extraction for .NET applications.
