CentralLogger.Client 2.0.0

CentralLogger.Client

This is the all-in-one package for adding CentralLogger to a .NET application. It includes:

• CentralLogger.Client.dll and CentralLogger.Abstractions.dll.
• The framework-dependent Windows x64 CentralLogger.Service payload and its application dependencies, without bundled .NET runtime assemblies.
• Build-transitive deployment that copies the service to service\ beside your application output.
• Durable client spooling, automatic reconnect, installed-service startup, and portable-service startup.

Requirements

• .NET 10 or later application.
• Windows x64 for the included service executable.
• .NET 10 x64 Runtime installed on the service machine. The .NET SDK is needed only for development.
• Administrative rights only when permanently installing the Windows service.

Install

dotnet add package CentralLogger.Client --version 2.0.0

For a local package feed:

dotnet add package CentralLogger.Client --version 2.0.0 --source C:\path\to\publish\nuget

Build the application once. The output will contain:

YourApplication.exe
service\
  CentralLogger.Service.exe
  CentralLogger.Service.dll
  appsettings.json
  CentralLogger.Service.deps.json
  CentralLogger.Service.runtimeconfig.json
  ...application dependencies, including SQLite...

Start logging

Initialize once at application startup:

using CentralLogger;

Logger.Initialize("ATMApplication");

Create one logger for each class or component:

private static readonly Logger Log =
    new("CashDispenser", "$Workfile: CashDispenser.cs $", "$Revision: 1.0 $");

Write logs without waiting for the service or database:

Log.Debug("Starting dispense operation.");
Log.Info("Dispense completed.");
Log.Warning("Cassette level is low.");
Log.Error(exception, "Dispense failed.");
Log.Write("CashPresented", "Cash was presented to the customer.");

Applications do not call FlushAsync during normal use. Entries are queued durably and delivered in the background. A bounded automatic drain runs at process exit, and unacknowledged entries remain in the client spool for replay.

Service behavior

All applications connect to the same local named-pipe service and write to one central database. The default database is:

C:\ProgramData\Company\CentralLogger\CentralLogs.db

To write to one append-only JSON Lines file instead, set LoggerService:StorageMode to JsonLines and LoggerService:LogFilePath to an absolute .jsonl path in the service's appsettings.json, then restart the service. The default file path is C:\ProgramData\Company\CentralLogger\CentralLogs.jsonl. Client code stays the same. MaximumLogFileBytes, ArchiveDirectory, and MaximumArchives control file rotation. Use the included service command convert-file --input <logs.jsonl> --output <snapshot.db> to create an Advanced Viewer snapshot. File storage does not support SQLite indexing or the service's database date-range ZIP export.

If the installed CompanyCentralLogger Windows service is unavailable, the client locates service\CentralLogger.Service.exe from the application output and starts it in portable mode. Multiple applications may contain the payload; a machine-wide mutex ensures only one writer service is active.

Portable startup is deliberately unelevated because application build/output folders are commonly writable by the current user. For environments where the ProgramData location is administrator-only, install the included Windows service. If ElevatePortableService is explicitly enabled, also set an absolute ServiceExecutablePath located in an administrator-controlled, ACL-protected installation directory.

For a permanent Windows-service installation, run the included service\Install-Service.ps1 from an elevated PowerShell session. The service configuration is service\appsettings.json; database, retention, encryption, recovery, and archive settings belong to the service, not application projects.

Monitoring-agent commands

The included service executable can be called by another local process without affecting the running service:

.\service\CentralLogger.Service.exe status --pretty

.\service\CentralLogger.Service.exe export `
  --start "2026-10-01T08:00:00Z" `
  --end "2026-10-01T09:30:00Z"

status returns JSON with healthy, canAcceptLogs, canExport, service counters, storage status, and the available UTC range. export automatically creates one ZIP containing complete databases for fully covered backups, range-filtered databases for partial boundary sources, and manifest.json. Success prints the ZIP path. A range with no records prints error:no logs found; every other export failure prints error:<short description>. Use --json for detailed success output. Exit codes are 0 for healthy/success, 1 for command failure, 2 for a completed but degraded/unavailable status, and 64 for invalid arguments. Sensitive sections remain encrypted in the extracted databases.