# Entry-Point Runtime — .NET / C#

## Signals to gather
- Framework-dependent: `dotnet <app.dll>` invocation.
- Adjacent `*.runtimeconfig.json` (parse `tfm`, framework references, roll-forward).
- Self-contained or single-file apps: ELF/PE with `DOTNET_BUNDLE`, `System.Private.CoreLib`, or `coreclr` markers.
- ASP.NET hints: `ASPNETCORE_URLS`, `appsettings.json`, presence of `wwwroot`.
- 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 `dotnet` is 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 exec` wrappers the same as `dotnet <dll>`.

## Evidence & scoring
- Large confidence boost when both host (`dotnet`) and DLL artefact are present.
- Add evidence for runtimeconfig parsing (`"runtimeconfig TFM=net8.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—should fall back to C/C++ detector.
- PowerShell-launched apps: ShellFlow should rewrite before the detector runs.
- Side-by-side deployment where multiple DLLs exist—prefer the one passed to `dotnet` or specified via `DOTNET_STARTUP_HOOKS`.