Dennis Doomen

It’s not overengineering—it’s the foundation for observability, maintainability, and sane operations.

#logging #exceptionhandling #lessonslearned #architecture #consultancy #avivasolutions

These decisions may seem small, but they are crucial for successful production use. And once things go sideways, cleaning it up is a costly, frustrating task. So make those decisions before the first try/catch hits the codebase. (cont’d)

Or always wrap and rethrow? How should transient exceptions be handled, and should retries be logged differently? If you don’t decide this early, your logs will become inconsistent, your monitoring unreliable, and your debugging painful. (cont’d)

And when to log at all. Just as importantly, you need to define what not to log—especially when sensitive data is involved. The same goes for exceptions. What types should be thrown and when? Should you ever catch and swallow? (cont’d)

That’s what happens when you don’t define your logging and exception strategy upfront. And no, it’s not “just common sense.” Teams need to clearly document what each logging level means, what qualifies for a warning vs. an error. (cont’d)

Sometimes the log makes it look like the world is on fire—only to realize someone just used the wrong log level. Or worse, the real issue is buried beneath irrelevant noise because no one agreed on what should be logged in the first place. (cont’d)

We’ve all been there — staring at a wall of log entries in Azure App Insights or your local console, trying to make sense of a flood of warnings, errors, and stack traces that lead… nowhere. You dig, you filter, you search, but instead of answers, you find noise. (cont’d)

PackageGuard 1.5 includes a couple of new features as well as bug fixes.

- Support for .slnx format
- Allow denying prerelease packages
- Display the version in output log
- Fix license detection of NUnit and NETStandard.Library

Read more about PackageGuard at github.com/dennisdoomen...

The second half of 2025 promises to as exciting as the first half was. Can't wait to engage with the developer community all over Europe.

We do that too. Whenever there's a 409, 404, 400/422, we include the reason as a message. Otherwise the caller has to rely on the OpenAPI docs to understand what went wrong, which is costly and incomplete.

In the end, status codes aren’t just numbers. They’re part of your contract. Get them right, and your API becomes easier to use, debug, and evolve. Get them wrong, and even the best backend logic won’t save the experience.

#httpapi #apidesign #restapis #lessonslearned #bestpractices #consultancy

And think long-term. Some decisions—like the color of your buttons—are easy to reverse. But your HTTP strategy? Once it’s baked into clients, docs, and SDKs, changing it is expensive. Choose carefully up front, and save yourself future pain. (cont'd)

Some things aren’t fully standardized yet. You’ll find teams using 409 (Conflict) for business rule violations, while others treat those same situations as 400 Bad Request. That ambiguity is where friction starts. Document your choices and stick to them. (cont'd)

That’s why it pays to be intentional about which HTTP codes you use, and when. Consistency beats cleverness here. Whether it’s 200 vs. 204 for a successful POST, or 400 vs. 422 for invalid input, what matters most is that your team—and your consumers—know what to expect. (cont'd)

When building HTTP APIs, clarity is everything. Developers rely on status codes not just to confirm success, but to understand what went wrong—and what to do next. If your API can’t communicate that cleanly, you’re not just confusing clients—you’re slowing everyone down. (cont'd)

What's the most satisfying (>2000 piece) #lego set you've built recently? I'm looking for something after I finally finish the Ferrari Daytona.

I've you've been using the JetBrains Annotations NuGet package to give hints to Rider on how code is used inside and outside your codebase, there's a source-only version of that package that will help avoiding the dependency hell. See www.nuget.org/packages/Jet...

Copilot autonomously providing a GitHub pull request for a feature or issue in my open-source projects is truly amazing to see. github.com/dennisdoomen...

Last weekend, I've pushed a small improvement to Pathy, a small open-source project for fluently building and using file and directory paths without binary dependencies. Check out the read-me at github.com/dennisdoomen...

My "early access" Teams regularly stops the incoming video (as well as that of my camera) while sharing a window. It's an i7-14700K with an RTX 5080. I have to kill and restart Teams to fix this. Has anybody observed something similar.

If you're wondering what this is about, check out www.dennisdoomen.com/2025/06/libr...

* Renamed the initial class that is generated to MyClass to prevent conflicts with the namespace
* Ensured the Roslyn analyzers are really running
* There was a conflict in the template names, resulting in a warning when installing the templates

This week, I've shipped a new version of the .NET Library Starter Kit. Version 1.4 comes with several improvements:

* Employ PackageGuard 1.4's caching to speed-up license scanning
* The assemblies build by the template's solution were not versioned correctly.
* Minor tweaking of the .editorconfig

I wish 🫣

Check out the full release notes at github.com/dennisdoomen...

Release 1.4.1 · dennisdoomen/packageguard What's Changed Improvements Added --github-api-key option to avoid GitHub rate limiting errors by @dennisdoomen in #52 Added --use-caching flag to maintain a persisted cache to speed-up the analys...

Version 1.4 solves that by providing two new options.

--use-caching will keep a persistent cache containing the most recent license information that you can store in source-control.

--github-api-key allows you to provide a Personal Access Token that PackageGuard will use to access the GitHub API.

One of the challenges in building #PackageGuard is to extract the license information from either the GitHub repository or some other internet location. This process takes quite some time and slows down the analysis and sometimes even causes rate-limiting errors coming from GitHub.

Code review in the age of AI: Why developers will always own the merge button When it comes to merging code, developers will always make the final decision. But we’re rethinking how tools like GitHub Copilot can help.

A very nice perspective on AI tooling by GitHub that I fully support (and recognize). See github.blog/ai-and-ml/ge...

Illustration of .net bot in a racecar submarine. text reads: .NET 10 Preview 6

HEY! .NET DEVS!!
Join the .NET team as we show off the latest features in .NET 10 Preview 6!
Streaming LIVE, HERE in just a few minutes ➡️ https://msft.it/63327s61wS
#dotnet #aspnet

Last weekend, we've pushed #FluentAssertions 8.5 to NuGet. It comes with a feature that we've been trying to finish for at least two years; the ability to have "BeEquivalentTo" optionally assert that the types of the objects and properties match as well.

See fluentassertions.com/releases/#850