Development with a Dot

Introduction To get the new year started, another post on my ASP.NET Core Pitfalls series! This time, it's related to APIs, and how the [Consumes] attribute is interpreted. The Problem The Content-Typ e header and optional charset parameter are part of the web standard and used to tell the server handler what type of content the client will send. The charset part is optional, and the default is " ascii "; for example, if we wish to set it as UTF-8 , we should sent: Content-Type: application/json;charset=utf-8 Now, charset is optional, and does not really change what the content type is, just the character set of the text of the payload. In ASP.NET Core, it can be used to route the request to different endpoints: for example, two action methods for the same action can consume different content types. There is an attribute,  [Consumes] , which can be used in ASP.NET Core MVC to restrict the content types that are accepted by a given action method. [HttpGet("Get...

Introduction When we have more than one action method in MVP or Web API that can match a given request, the request may fail or land on an unwanted method. By default, a number of items is used to figure out which method to call: The HTTP verb The action method name The route template The action method parameters The request content type An  action constaint  may be needed to select the right one; an action constraint is an implementation of IActionConstraint , and is normally added through an attribute or a convention. Some examples of built-in action constrains include: [Consumes] attribute: for selecting the method based on the Content-Type request header HttpMethodActionConstraint : legacy, don't bother OverloadActionConstraint : the method selected must match all required parameters If you want to build your own, you should inherit from  ActionMethodSelectorAttribute  and implement  IsValidForRequest . Problem Sometimes, however, just applying an acti...

Introduction Another on my EF Core pitfalls series. This time, interceptors and synchronous/asynchronous calls. Problem You surely know about EF Core interceptors , a very useful feature that I talked about many times. What's the problem with them? Well, all of the interceptor interfaces  define both synchronous as well as asynchronous versions of their methods. This is so that, for example, when we call DbContext.SaveChanges the synchronous version is called, and when it's DbContext.SaveChangesAsync , the asynchronous one instead. I think you get the idea. So, imagine we added an interceptor, inheriting from SaveChangesInterceptor ,   to our collection of interceptors . If we then commit the changes in the  DbContext  through a call to  DbContext.SaveChanges , only SavingChanges , SavedChanges , SavedChangesFailed ,  SaveChangedCanceled  and, or, ThrowingConcurrencyException methods will be called, and you may be very surprised because your well-cra...

Introduction Another one for my series on Entity Framework Core Pitfalls. Sometimes, even when using EF Core, we need to perform some operations, like calling a database (DB) function, that is not mapped to LINQ. We've been able to do this for a long time, and it is certainly the case with EF Core. Let's see how. Calling DB Functions in LINQ Queries So, some standard DB functions have been mapped to EF.Functions , as part of the DbFunctions class, but there are a big number of them that haven’t. Some examples include SQL Server's  REVERSE ,  SOUNDEX , DIFFERENCE , and many others. Now, there's a way to call them in LINQ queries, but there is a (minor) caveat. One way to do this is to have a method in your DbContext -derived class, which can be static or instance, such as: public string Reverse(string property) => throw new NotImplementedException("Only to be called in an EF Core LINQ query."); }; Now, we need to tell EF Core to use this function, and there...

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...