7 posts tagged with "dotnet"

With every upgrade of a major version of AutoMapper there are many things that break. Recently I've been involved in upgrading not one or two majors but from 8.x to the latest and presumably greatest 13.0.1. After removing calls to obsolete methods, removing duplicate and explicitly added mappings of child types that previously was inferred. The migration was done. The confidence was high as the unit tests that verified the mapping configuration passed:

new MapperConfiguration(cfg => cfg.AddProfile<Profile>())
  .AssertConfigurationIsValid();

A few seconds after the code was deployed errors started to appear in the application log.

That's strange.

There are a few resemblance between a CI pipeline and a kitchen sink. When it has just been installed it does its job efficiently and after a while its functionality is taken for granted. But the same way that a sink becomes clogged over time, a pipeline tend to grow slow, complex and/or bloated. An just like with the sink, the change is incremental and slow that it's hard to notice the decay. And lastly, before this comparison is put aside: they are both integral components in crucial workflows.

Ever been to one of those aggregating search sites where the result list is populated in chunks, rather than all at once? Ever wondered how it works? Event driven sites are robust, extendable - and if you're on a messaging system like RabbitMQ and a .NET client like RawRabbit, it is pretty easy to get started.

It is indeed a change of mindset to break up larger applications into smaller, contained services. One aspect of the transition, that is often somewhat overlooked, is the log file havoc that often sneak up on you when you least want it.

Logging is inherently difficult to make right. I believe one reason for this is that as a developer, running the application locally, there are better tools available for understanding what's going on. .NET developers has been spoiled by the first class debugging experience in Visual Studio for quite some time. My experience is that logging is often an after-thought to a period of optimistic testing.

Logging is often an after-thought to a period of optimistic testing.

The date for the next major release of RawRabbit is drawing nearer. It is more than a year ago since I decided to implement a .NET Core[^1] client for RabbitMq. During this time, I've discovered some differences between developing a library and an application.

A few days ago, I asked the RabbitMq community for input on what is missing in todays high level .NET clients. One of the topics that came up was the ability to control the concurrency of messages consumed. This has been discussed before, so I thought I'd implement it for RawRabbit.

I wasn't thrilled when Owin was introduced back in 2012. Sure, I could see the benefits in an abstraction layer between the web server and the application, but I didn't really see the full potential of the ecosystem of middlewares that came about a few months later. Then, for a long time, my only relation to these middleware was through extension methods like

public void Configuration(IAppBuilder app)
{
    app.UseFoo();
    app.UseBar();
}