Sujet : dotnet
-
Conventions d'injection de dépendances en .NET : durées de vie, portées et piège de la dépendance captive
Microsoft.Extensions.DependencyInjection enregistre les services dans un IServiceCollection avec une durée de vie transient, scoped ou singleton et les injecte via des constructeurs publics ; les règles documentées sont de ne jamais injecter un service scoped dans un singleton, de laisser le conteneur libérer ce qu'il a créé, d'éviter les appels de type localisateur de services et de valider les portées pour que les dépendances captives provoquent un échec au démarrage plutôt qu'un partage d'état indu entre requêtes.
-
Which observability signals should a JVM or .NET service emit by default, and at what overhead?
Open question: both runtimes ship built-in telemetry (Flight Recorder and GC logging on the JVM; EventPipe counters and dotnet-trace on .NET) and both have OpenTelemetry auto-instrumentation, but there is little shared evidence on which of these should be always-on in production, what they cost, and which ones actually shortened incidents.
-
Writing a unit test in JUnit 5 and xUnit.net: annotations, lifecycle and parameterised cases side by side
JUnit Jupiter marks tests with @Test, runs @BeforeEach and @AfterEach around each one on a fresh instance by default, and drives data-driven cases with @ParameterizedTest plus a source annotation; xUnit.net uses [Fact], the constructor and IDisposable for per-test setup on a fresh instance, [Theory] with [InlineData] for cases, and fixtures for shared expensive context. Writing tests with the same shape in both keeps a polyglot team's conventions aligned.
-
C# async/await pitfalls: sync-over-async, async void and ConfigureAwait
The classic mistakes in C# asynchronous code are blocking on a Task with .Result, .Wait() or GetAwaiter().GetResult() (deadlocks under a single-threaded SynchronizationContext, thread-pool starvation on servers), async void methods whose exceptions cannot be caught, and misplacing ConfigureAwait(false), which belongs in general-purpose libraries and not in application code.
-
Pinning NuGet dependencies: PackageReference, central package management and packages.lock.json
NuGet resolves the lowest applicable version of each package at restore time, so a restore can drift when new versions or floating ranges appear; a repeatable build declares versions once in Directory.Packages.props, enables RestorePackagesWithLockFile so packages.lock.json records the full closure, commits the lock file for applications, and restores with --locked-mode in CI.
-
Nullable reference types in C#: a compile-time contract, not a runtime check
With <Nullable>enable</Nullable> the C# compiler treats string as non-nullable and string? as nullable, tracks the null-state of every expression and warns on mismatches; nothing changes at run time, string and string? are the same type, and the null-forgiving operator ! plus the nullable-analysis attributes ([NotNullWhen], [MemberNotNull]) are how you tell the compiler what it cannot infer.
Lisible par machine : JSON