Herald.DemoApp 0.12.8

Herald.DemoApp

The five-minute getting-started experience for Herald.OSS, the open-source structured-logging core for .NET.

Install it, run it, open the URL it prints, and watch a real Herald.OSS pipeline process live log events. Then program that pipeline — levels, minimum level, flight recorder, enrichers, sinks — from the embedded Live Viewer, and watch your changes take effect on the next event.

Install

dotnet tool install --global Herald.DemoApp

Requires a .NET 8 (or newer) runtime with the ASP.NET Core shared framework. If you build .NET web apps, you already have it.

Run

herald-demo

The console prints one line — the URL to open:

Herald DemoApp is running.
Open http://localhost:5210 in your browser.
Press Ctrl+C to stop.

Open that URL. You land on the Live View tab with log events already flowing. Switch to the Pipeline tab to change how the pipeline behaves; switch to JSON Pipeline to see the live config. No setup, no config files, no build step.

What you are looking at

This is not a mock. A real Herald.OSS pipeline runs inside the tool:

• A source feeds synthetic log events through the canonical Default pipeline strategy.
• The pipeline fans out to two real sinks: a console sink (terminal output) and an HTTP-JSON sink that loops back so the browser sees the same stream.
• The Live Viewer programs that pipeline live. Add a level, change the minimum level, toggle the flight recorder, add an enricher — the pipeline rebuilds and the change shows on the next event.

Want to send your own events? POST newline-delimited JSON log envelopes to /api/logs/incoming. The synthetic feed steps aside while a real producer is active, so your events flow through the same pipeline you see on screen.

Flags

The happy path needs none of these. They exist for when you want them.

Update / uninstall

dotnet tool update --global Herald.DemoApp
dotnet tool uninstall --global Herald.DemoApp

Note

This is a demo tool, not a production server. It runs with no authentication and a wide-open dev CORS policy by design — it is meant to run on your own machine so you can see how Herald works. Real Herald deployments host the API through Herald.RestApi.Host and configure their own auth and CORS.

Building the release package

Local dev binds the live /e/dev/Herald.OSS sibling source so an edit to the core shows up in the demo immediately. The published tool must instead bundle the released Herald.OSS package, so the release pack passes HeraldDemoAppReleaseRef=true. That flips the FakeServer's own Herald.OSS reference, the two sink references, and the licensing references onto the released package pinned at HeraldDemoAppCoreVersion (in Directory.Build.props), keeping one released Herald.OSS identity across the whole tool.

cd samples/DemoApp
dotnet pack -c Release -o ./release-out \
  -p:HeraldDemoAppReleaseRef=true \
  -p:HeraldLicensingForkCoreRef=false \
  -p:HeraldSinkForcePackageRef=true \
  -p:HeraldSinkForcePackageVersion=0.12.0

Bump HeraldDemoAppCoreVersion, HeraldSinkForcePackageVersion, the Directory.Packages.props Herald.OSS pin, and the package <Version> together in lockstep with the Herald.OSS release the DemoApp ships against.

License

Apache-2.0. Copyright (c) 2026 MMPWorks LLC.