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.