Development with a Dot

This is another post on my ASP.NET Core pitfalls series . It is actually related to this one  ASP.NET Core Pitfalls – Null Models in Post Requests . What happens if you try to submit a string containing JSON as a POST? I mean, you always submit strings, but this time you don't want for it to be parsed into some class. Like this: [HttpPost] public IActionResult PostString([FromBody] string json) { ... } You may be surprised to find out that this fails with a HTTP 415 Unsupported Media Type . Now, you might be tempted to add an [Consumes] attribute to it, such as: [HttpPost] [Consumes("application/json")] public IActionResult PostString([FromBody] string json) { ... } And this will actually work! The problem is, or could be, that it requires the sender to send the appropriate Content-Type header (" application/json "). Another, better, solution is to just read the string from the from the request stream: [HttpPost] public IActionResult PostString() { using v

Introduction You're most likely familiar with HttpClient and its recommended usage , which involves calling one of the overloads of AddHttpClient . One thing that you may or may not have noticed is, even though you call the overload that takes a name for the client, it is not registered in the dependency injection (DI) container as such. So I went out to fix this! So, what we want is that any named clients can be also registered with the DI container, which will allow us to retrieve them by the service type and key: var googleClient = serviceProvider.GetRequiredKeyedService<HttpClient>("Google"); or: public IActionResult Index([FromKeyedServices("Google")] HttpClient googleClient) { ... } So, as of now, the only way to obtain the named client is by using  IHttpClientFactory 's CreateClient method: var googleClient = serviceProvider.GetRequiredService<IHttpClientFactory>().CreateClient("Google"); Which is fine, but just takes some extr

Introduction We all use Internet search. Nowadays, bookmarks have become somewhat outdated, as the modern search engines are so good at finding what we want, that they have become somewhat obsolete. But, what if we need to perform a search in code? We can obviously send an HTTP request to our search engine of choice and then parse the result, but it would be useful if there was a library that could do it for us. And this is how Search.NET was born! Concepts First, let's define a contract for a search proxy in .NET. A concrete proxy implementation will be specific to a search engine, such as Google , or Bing , but the contract will be the same. Here is what I propose, a contract named ISearch : public interface ISearch {     Task<SearchResult> Search(string query, CancellationToken cancellationToken = default); Task<SearchResult> Search(string query, QueryOptions options, CancellationToken cancellationToken = default); } As you can see, it has essentially one Se

Introduction In the past, I already wrote about the .NET service provider, including some gotchas ,  recent changes , and its history . Now, I'm going to talk about something different. There are multiple open tickets , which include some features, for the .NET service provider. Having experienced some issues myself, I decided to augment the built-in provider with some features that I find useful, so here we are. Problems With this implementation, I wanted to overcome a few issues: Being able to provide my own service instance, at runtime (dynamically); note that this is already possible, as you can specify a factory method that will be called when the service is requested, but I wanted a different thing, more dynamic Being able to hook into the service provider and do things to services once they are obtained; this allows, for example, setting property values or doing any kind of instantiation Let's see how this works, enter the ExtendedServiceProvider ! The ExtendedServicePro

Introduction You may remember my post on the Domain Events framework I created, a few days ago. Well, I've been working on it, cleaning things a bit, correcting a few bugs, and I introduced two new features/concept:  Event interceptors can now return a boolean from the BeforePublish event in order to cancel the publication of the event Event transformers Changes to Event Interceptors The changes to the IDomainEventInterceptor / IDomainEventInterceptor<TEvent> interface look like this: public interface IDomainEventInterceptor { ValueTask<bool> BeforePublish(IDomainEvent @event, CancellationToken cancellationToken = default); Task AfterPublish(IDomainEvent @event, CancellationToken cancellationToken = default); } public interface IDomainEventInterceptor<TEvent> where TEvent : IDomainEvent { ValueTask<bool> BeforePublish(TEvent @event, CancellationToken cancellationToken = default); Task AfterPublish(TEvent @event, CancellationToken cancellat

Introduction Domain Events  is a pattern and concept made popular by Domain Driven Design . A Domain Event is something that happened on your system and you want interested-parties to know about. It is a way to publish information in a decoupled, usually asynchronous, way. A publisher publishes (raises) an event, and interested subscribers receive a notification and act accordingly. A subscriber can also be a publisher, of course. In this post I'm going to present a Domain Events library for .NET. It's not the first time that I write about decoupling messages and subscribers in an application, I implemented a few years ago the Postal.NET library which does something similar. Mind you, there are many implementations out there, MediatR coming first to my mind, but this is mine. I obviously got some ideas from other implementations, but mine is substantially different from all the others. Concepts First, a few concepts: An event is just some class that implements IDomainEvent A

Welcome to my new blog! As some of you may know, I already had a blog (since 2009), which was (and is) https://weblogs.asp.net/ricardoperes . For a few reasons, I decided to move to a different platform, and here we are. The old blog will still be there, but all the new posts will go here; it is possible that sometimes I will reference posts from there. I hope to see you here and hearing from you soon!