dotnet-extensions-logging

Enforce ILogger<T> usage with logger-first constructor ordering in .NET projects.

Updated Mar 29, 2026
One-click install
npx skills add https://github.com/Muhomorik/KanelBulleKapital --skill dotnet-extensions-logging
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dotnet-extensions-logging
Source: https://github.com/Muhomorik/KanelBulleKapital/tree/main/.claude/skills/dotnet-extensions-logging
Command: npx skills add https://github.com/Muhomorik/KanelBulleKapital --skill dotnet-extensions-logging

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill standardizes and enforces proper usage of Microsoft.Extensions.Logging.ILogger<T> across .NET projects, reducing logging inconsistencies and improving maintainability.

Core Features & Use Cases

  • Enforces ILogger<T> usage and places the logger as the first constructor parameter
  • Promotes null-checks, deferred formatting, and proper exception logging
  • Guides integration with DI containers and common .NET logging practices

Quick Start

Apply the conventions to implement and validate ILogger<T> usage in service constructors, ensuring the logger is the first parameter, null checks are present, and messages use structured logging.

Frequently Asked Questions about dotnet-extensions-logging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce consistent ILogger<T> usage across dependency-injected .NET services?▼

Enforce ILogger<T> logging conventions by standardizing constructor parameter ordering, applying null-checks, and validating structured logging patterns across all injected service classes in .NET applications.

What is the best way to structure constructor parameters for logging in C# dependency injection?▼

Structure constructor parameters by placing ILogger<T> as the first argument, followed by null-checks to ensure safe, structured logging and consistent dependency injection across typical application layers.

How does structured logging work with Microsoft.Extensions.Logging in .NET projects?▼

Structured logging with Microsoft.Extensions.Logging uses ILogger<T> to defer message formatting, properly log exceptions, and integrate with common DI containers, ensuring consistent and maintainable logging practices.

Can I use this logging convention guide for non-DI .NET components?▼

This convention applies to dependency-injected classes and typical application layers, ensuring safe structured logging. It prescribes constructor ordering and null-checks specifically designed for DI container integration scenarios.

Why should the logger be the first parameter in a .NET service constructor?▼

The logger should be the first parameter to enforce consistent ILogger<T> usage conventions across .NET projects, reducing logging inconsistencies and improving maintainability by standardizing dependency injection patterns.

What are the limitations of enforcing structured logging conventions in .NET?▼

The conventions specifically target dependency-injected classes using ILogger<T>, covering error handling scenarios and common DI containers, but may not apply to static classes or non-DI architectural patterns.