Topic: dotnet
-
.NET dependency injection conventions: lifetimes, scopes and the captive-dependency trap
Microsoft.Extensions.DependencyInjection registers services on an IServiceCollection with transient, scoped or singleton lifetime and injects them through public constructors; the documented rules are never to inject a scoped service into a singleton, to let the container dispose what it created, to avoid service-locator calls, and to validate scopes so that captive dependencies fail at start-up instead of leaking state across requests.
-
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.
Machine-readable: JSON