Primero de todo, va una pildorilla cultural coincidiendo con el número de entrega de la serie de enlaces.

Cuando un servidor HTTP está expuesto a sus clientes a través de un intermediario (proxy,  gateway, balanceador o cualquier otro tipo de sistema), es dicho intermediario el que recibe en primera instancia las peticiones, reenviándolas a su destino final y retornando su respuesta. Esto se realiza de forma totalmente transparente para el cliente.

El error HTTP 502 (Bad gateway) es retornado por los servicios intermediarios (proxies,  gateways, etc.) cuando no pueden obtener una respuesta válida desde el servidor de destino real de la petición. Por ejemplo, podría ocurrir si éste esté caído, parado por mantenimiento o desconectado de la red, entre otros motivos.

Por si te lo perdiste...

• Cómo personalizar el mensaje "Loading" de las aplicaciones Blazor WebAssembly
  José María Aguilar
• Cómo describir los elementos de una enumeración usando métodos de extensión y atributos (C# y VB.NET)
  José María Aguilar

.NET Core / .NET

• Read CSV File in .NET using CsvHelper
  Bradley Wells
• Differences between .NET Collection Interfaces
  Matt Eland
• Automatically version and release .Net Application
  Anto Subash
• IComparable vs IComparer vs Comparison Delegate
  Muhammed Saleem
• Dictionary vs Hashtable in C#
  Code Maze
• The Forgotten Art of C# Inheritance
  Szymon Kulec @Scooletz
• C# 11 File Scoped Types
  Patrick Smacchia
• Using WASM and WASI to run .NET 7 on a Raspberry PI Zero 2 W
  Laurent Kempé

Modificadores de visibilidad habituales como internal, public o private nos acompañan desde los inicios de C#, permitiéndonos definir desde dónde queremos permitir el acceso a los tipos que definimos en nuestras aplicaciones. Así podemos indicar, por ejemplo, que una clase pueda ser visible sólo a miembros definidos en su mismo ensamblado, que pueda ser utilizada desde cualquier punto, o que un tipo anidado sólo pueda verse desde el interior de su clase contenedora.

Pues bien, C# 11 traerá novedades al respecto ;)

Disclaimer: lo que vamos a ver aquí es válido en la RC2 de .NET 7, pero aún podría sufrir algún cambio para la versión final, prevista para noviembre de 2022.

El error HTTP 501 "Not implemented" se utiliza para indicar al lado cliente que el servidor no soporta las funcionalidades necesarias para poder dar una respuesta a la petición. Puede retornarse acompañado del encabezado Retry-After para indicar al cliente que puede volver a intentarlo más adelante, cuando estas funcionalidades hayan sido implementadas.

Por ejemplo, la MDN, indica que es la respuesta apropiada cuando el servidor no implementa el método HTTP utilizado en la petición ni para el recurso solicitado ni para cualquier otro. Fijaos que hay una diferencia respecto al error 405, que indica que el recurso está disponible con otro verbo HTTP.

Y ahora, ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• Componentes con cuerpo en Blazor
  José María Aguilar
• Efectos laterales en métodos parciales
  José María Aguilar

.NET Core / .NET

• Introducing Spectre.Console
  Steve Smith
• That Shouldn't Happen - UnreachableException in .NET 7
  Abbot
• Simplify NuGet Package Versions in your application with Central Package Management
  Nick Randolph
• Make The First Letter of a String Upper Case in C#
  Code Maze
• 8 reasons startups prefer Node.js over .NET, and are they justified?
  Michael Shpilt
• Accessing State in System.Text.Json Custom Converters
  Steve Gordon
• 3 (and more) ways to set configuration values in .NET
  Davide Bellone
• Task.ContinueWith implicit type conversion gotcha
  Maciej Zwierzchlewski
• Common C# Programming Mistakes
  Code Maze
• Generating Code Coverage Reports in .NET Core
  Anuraj Parameswaran
• Update on ImageSharp
  .NET Foundation
• Throwing exceptions - Why is my stack trace lost?
  Steven Giesel
• Builder Pattern with the implicit operator using
  Josef Ottosson

Normalmente, nuestras aplicaciones web ASP.NET Core son hosteadas por aplicaciones de consola, que son las encargadas de crearlas, configurarlas y lanzarlas. Esto suele hacerse mediante una relación de uno a uno: una única aplicación de consola se encarga de gestionar todo el ciclo de vida de una única aplicación web.

Pero, ¿es así necesariamente? En este post veremos que no.

Pues no habría apostado a que llegaríamos tan lejos, pero sí, estamos ante la entrega número 500 de la serie de enlaces interesantes, un post semanal que recoge los mejores contenidos técnicos que voy encontrando por la red, y que me consta que a muchos también os resultan interesantes :)

Ya cuando la serie cumplió diez años publiqué un post respondiendo preguntas que me habéis hecho y seguís haciendo sobre ella, así que si tenéis curiosidad sobre como empezó, el tiempo que dedico a ello o criterios para seleccionar los enlaces, os recomiendo que echéis un vistazo al post, porque todo sigue vigente.

Y ahora, vamos al lío: ahí van los enlaces recopilados durante la semana pasada que, como de costumbre, espero que os resulten interesantes. :-)

Por si te lo perdiste...

• Métodos parciales en C# 3 y VB.NET 9
  José María Aguilar
• Cómo mostrar el número de usuarios conectados a una aplicación Blazor Server, en tiempo real
  José María Aguilar

.NET Core / .NET

• Announcing .NET 7 Release Candidate 2
  Jon Douglas & Jeremy Likness & Angelos Petropoulos
• Console.ReadKey improvements in .NET 7
  Adam Sitnik
• Boosting Performance With Sealed Classes in .NET
  Marko Hrnčić
• Low-level struct improvements in C# 11
  Steven Giesel
• Calculating MRR with Stripe and C#
  Phil Haack
• Cursed C# - Doing shenanigans in C#
  Steven Giesel
• What's new in System.Text.Json in .NET 7
  Eirik Tsarpalis & Krzysztof Wicher & Layomi Akinrinade
• Modern C# Techniques, Part 3: Generic Code Generation
  Stephen Cleary
• Functional Programming in C#—A Brief Consideration
  Assis Zang
• Infographics Compendium II - ThrowHelper, null Task and more
  Steven Giesel

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• Otras 101 citas célebres del mundo de la informática
  José María Aguilar
• Capturar todos los parámetros enviados a un componente Blazor
  José María Aguilar

.NET Core / .NET

• Adiciones a LINQ en .NET 7.0
  Octavio Hernandez
• Understanding identity in .NET
  Pierre Bouillon
• Sorting in C#: OrderBy.OrderBy or OrderBy.ThenBy? What′s more effective and why?
  Sergei Vasiliev
• Ensuring best practices for NuGet packages
  Gérald Barré
• Write barrier optimizations in regions
  Maoni Stephens
• Bending .NET - Compiling 65,536 Programs with Roslyn to Find Valid Identifier Separator char's... then just use SyntaxFacts.IsValidIdentifier 🤦‍
  Niels Rasmussen
• How to build a URL Shortener with C# .NET and Redis
  Niels Swimberghe
• Bing Ads Campaign Platform – Journey to .NET 6
  Mike Treit
• Modern C# Techniques, Part 2: Value Records
  Stephen Cleary

Las inline route constraints, o restricciones de ruta en línea son un interesante mecanismo de ASP.NET Core para especificar condiciones sobre los parámetros definidos en el interior de los patrones de ruta.

Por ejemplo, una acción MVC o un endpoint mapeado usando el patrón /product/{id}, será ejecutado cuando entren peticiones hacia las rutas /product/1 y product/xps-15. Sin embargo, si en el momento del mapeo utilizamos el patrón /product/{id:int} estaremos indicando que el manejador sólo debe ser ejecutado cuando el valor del parámetro id sea un entero.

Esto podemos verlo mejor en un ejemplo. Observad la definición de la siguiente acción MVC, que será ejecutada sólo si el valor para el parámetro id es un entero, es decir, responderá a peticiones como /product/1 o /product/234, pero será ignorada si la petición entrante se dirige a la ruta /product/xps-15:

public class ProductController : Controller
{
    ...
    [HttpGet("product/{id:int}")]
    public async Task<ActionResult<Product>> ShowDetails(int id)
    {
        var product = ... // Obtener producto
        return product != null ? product:  NotFound();
    }
}

O lo que sería su equivalente usando las minimal APIs introducidas en .NET 6:

app.MapGet("/product/{id:int}", async (int id) =>
{
    var product = await new ProductCatalog().GetByIdAsync(1); // Obtener producto
    return product != null ? Results.Ok(product) : Results.NotFound();
});

Como ya habréis adivinado, en {id:int} es donde estamos especificando que el parámetro de ruta id debe ser entero.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• Clases parciales en C# y VB.NET
  José María Aguilar
• Mostrar HTML "crudo" en componentes Blazor
  José María Aguilar

.NET Core / .NET

• Use .NET from any JavaScript app in .NET 7
  Pavel Šavara
• How to Use Shouldly to Improve Unit Tests in .NET?
  Code Maze
• Microsoft Commerce's .NET 6 Migration Journey
  Kurtis Story
• How to generate a dump file of a .NET application
  Gérald Barré
• The ThreadPool in .NET 7 NativeAOT uses the Windows thread pool
  Austin Wise
• Introducing C#11: Auto Default structs
  Anthony Giretti
• Pattern matching is awesome
  Steven Giesel
• Generate Dynamic PDF Reports from an HTML Template Using C#
  Praveen Kumar
• Microsoft Teams’ Infrastructure and Azure Communication Services’ Journey to .NET 6
  Siavash Fathi & Arman Raina & Bhaskar Bhattacharya
• .NET: Learn LINQ as you never have before
  Anthony Giretti
• x86 vs x64 in .NET
  Steven Giesel
• By Reference in C#
  Peter Ritchie
• Modern C# Techniques, Part 1: Curiously Recurring Generic Pattern
  Stephen Cleary
• Generate Strongly-Typed Resources with .NET Core
  Travis Illig
• Infographics Compendium I - Generators, pure functions and more
  Steven Giesel