NeonLog.CSharp 0.1.0-ci.40

C# wrapper

This folder contains a thin C# wrapper for neonlog-c built with P/Invoke against the stable C ABI exported from include/neonlog/neonlog.h.

Projects

• NeonLog.CSharp targets netstandard2.0 and exposes managed logger, factory, sink, and value types.
• NeonLog.CSharp now also includes NeonLogConfigurationOptions and NeonLogPropertyOptions so appsettings-bound configuration can live in the wrapper instead of the sample.
• NeonLog.CSharp can now read both the wrapper-native options shape and the original NeonLog WriteTo / Properties / Enrich settings shape through NeonLogConfigurationOptions.FromConfiguration(...).
• NeonLog.CSharp also integrates with Microsoft.Extensions.Logging, so the package can be registered as the app's standard ILogger provider with builder.Logging.AddNeonLog(...).
• NeonLog.CSharp.Sample is a console app that binds NeonLogConfigurationOptions from appsettings.json and exercises the factory API from C#.
• NeonLog.CSharp.PackageTests is an xUnit consumer project that restores the packed NuGet package from the local package feed and exercises the full supported API surface.

Package layout

NeonLog.CSharp is now packable as a single NuGet package that contains:

• the managed netstandard2.0 wrapper assembly
• runtimes/win-x64/native/neonlog.dll
• runtimes/linux-x64/native/libneonlog.so

GitHub Actions CI

The repository CI is defined in .github/workflows/ci.yml and does the entire packaging flow in GitHub Actions:

• builds and smoke-tests the native library on windows-latest
• builds and smoke-tests the native library on ubuntu-latest
• stages the platform binaries into artifacts/native/<rid>
• packs NeonLog.CSharp into a NuGet package that includes both native assets
• runs the package-consumer tests on Windows and Linux against the packed .nupkg
• publishes the .nupkg to GitHub Packages on tags matching v*

Every CI run also uploads the native binaries and the generated .nupkg as workflow artifacts.

The project expects staged native assets at:

• artifacts/native/win-x64/neonlog.dll
• artifacts/native/linux-x64/libneonlog.so

The generated .nupkg is written to artifacts/packages.

Build native assets

Stage the Windows native binary from Windows:

./bindings/dotnet/scripts/build-and-stage-native.ps1 -Configuration Release

Stage the Linux native binary from Linux:

./bindings/dotnet/scripts/build-and-stage-native.sh Release

Both files must be present before dotnet pack runs.

Pack the NuGet package

With both native assets staged and a .NET SDK installed:

dotnet pack bindings/dotnet/NeonLog.CSharp/NeonLog.CSharp.csproj -c Release

The pack target fails fast if either the Windows or Linux native asset is missing.

In GitHub Actions, the package version defaults to 0.1.0-ci.<run_number> for branch and pull request builds and uses the tag value for refs like v0.1.0.

Run the package consumer tests

The test project references NeonLog.CSharp via PackageReference, not via project reference. Restore and test it only after packing the local package:

dotnet test bindings/dotnet/NeonLog.CSharp.PackageTests/NeonLog.CSharp.PackageTests.csproj -c Release

The tests cover:

• ABI/version metadata lookup
• direct logger creation and configuration
• context loggers
• all log level helper methods
• all supported value kinds
• factory configuration with static properties
• console sink configuration
• original-style WriteTo / Enrich configuration parsing
• both Redis modes with sink-error isolation
• async-mode rejection

Original NeonLog compatibility

The wrapper now mirrors these original NeonLog configuration concepts directly:

• WriteTo: [{ Name, Args }] for Console, Redis, and RedisList
• Properties as a simple object map
• Enrich with Timestamp, ProcessInfo, Environment, LogScope, and HttpRequest
• outputTemplate on the console sink

Use NeonLogConfigurationOptions.FromConfiguration(...) when you want the wrapper to accept the same NeonLog section shape used by the Node.js package.

LogScope and HttpRequest are implemented in managed code with AsyncLocal helpers:

• NeonLogScope
• NeonLogHttpRequestContext

Microsoft ILogger integration

Use the wrapper as the application's standard logging provider:

using NeonLog;

var neonLogOptions = NeonLogConfigurationOptions
   .FromConfiguration(builder.Configuration.GetSection("NeonLog"));

builder.Logging.ClearProviders();
builder.Logging.AddNeonLog(neonLogOptions.ToFactoryOptions());

Or bind directly from configuration:

builder.Logging.AddNeonLog(builder.Configuration.GetSection("NeonLog"));

The provider maps:

• ILogger<T> categories to SourceContext
• structured message templates to native NeonLog template arguments
• BeginScope(...) values to per-event context properties
• EventId.Id / EventId.Name to EventId / EventName
• LogLevel.Critical to Fatal

Redis fallback buffering

NeonLogRedisSinkOptions now supports two failure-handling settings for sinks like Redis:

• FallbackToConsoleOnFailure: redirects buffered events to the console when Redis cannot connect or flush and no regular console sink is already configured.
• MaxBufferedEvents: caps the in-memory Redis backlog so the sink keeps only a bounded recent buffer instead of retaining every unsent event.

When fallback is enabled and Redis becomes unavailable, buffered events are written to the console and cleared instead of being retained indefinitely.

In CI, these tests restore NeonLog.CSharp from the just-packed local artifact feed under artifacts/packages so the package, not the source project, is what gets validated.

Build and run the sample

1. Build or stage a native library for your current platform.

   cmake -S . -B build
   cmake --build build --config Debug
   

2. Make the native library discoverable to the CLR at runtime. On Windows that typically means copying build\Debug\neonlog.dll next to the managed executable or adding that directory to PATH.

3. Build and run the sample with a .NET SDK installed:

   dotnet build bindings/dotnet/NeonLog.CSharp.Sample/NeonLog.CSharp.Sample.csproj
   dotnet run --project bindings/dotnet/NeonLog.CSharp.Sample/NeonLog.CSharp.Sample.csproj
   

Managed API surface

• NeonLogRuntime validates ABI compatibility and exposes native status and level names.
• NeonLoggerFactory wraps neonlog_logger_factory_* for advanced sink configuration.
• NeonLogger wraps both the direct config API and the logger API, including child loggers, level checks, and flush.
• NeonLogValue marshals UTF-8 strings, integers, doubles, booleans, and null values into the native union type.