Un año más, es una alegría enorme compartir con vosotros que Microsoft me ha reconocido por duodécimo año consecutivo como MVP (Most Valuable Professional) en la categoría de tecnologías de desarrollo. Aunque ha pasado bastante tiempo desde que me sorprendiera el mail con el primer nombramiento, sigo recibiéndolo con gran ilusión, el orgullo de seguir formando parte de esta familia y también la responsabilidad de intentar estar a la altura de este honor.
Y como en este mundo hay que entender de dónde y por qué llegan las cosas, no puedo sino haceros llegar mi eterno agradecimiento a todos los que habéis hecho este sueño posible: a los que visitáis de vez en cuando este rinconcillo de la red para obtener o compartir información, porque sois la gasolina que hace que este motor funcione; al equipo del programa MVP, por su incansable trabajo para conseguir que tengamos una gran comunidad de desarrolladores; y, por supuesto, a mis tres niñas, que asumen mis ausencias con la naturalidad de lo que siempre ha sido así.
Aprovecho también para enviar mis felicitaciones a compañeros que continúan siendo MVP (ya sabéis que no es sólo llegar, también mantenerse) y a los que hoy han recibido ese email con una de las mayores alegrías de su vida :)
¡Nos vemos por aquí!
Publicado en Variable not found.
Una de las (muchas) cosas buenas que trajo ASP.NET Core (y .NET Core en general) sin duda ha sido la popularización de la inyección de dependencias y la filosofía de implementación de componentes desacoplados que expone en múltiples puntos.
Esto ha provocado que en nuestras aplicaciones sea ya habitual encontrar secciones de código dedicadas al registro de decenas o centenares de servicios usando los distintos ámbitos disponibles (scoped, singleton o transient). El problema es que esta abundancia de servicios y la asiduidad con la que registramos nuevos componentes o modificamos sus dependencias hace que se nos puedan pasar por alto detalles que pueden hacer que nuestra aplicación falle. Por ejemplo, es fácil que olvidemos registrar algún servicio, o que, por un despiste, inyectemos servicios en componentes registrados con ámbitos incompatibles.
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Ojo a los antipatrones
José María Aguilar - Cómo implementar view-models de componentes Blazor en clases code-behind
José María Aguilar
.NET Core / .NET
- Rop.ProxyGenerator: Source Generator to create ProxyClasses
Ramón Ordiales - Async Enumerable in C# (Part 2)
Mark Heath - AlterNats — High Performance .NET
Yoshifumi Kawai - Ternary Operator ? : in C#
Code Maze - Merging concurrent IAsyncEnumerable<T> operations for increased performance
Stefan Schranz - ZString — Zero Allocation StringBuilder for .NET Core and Unity.
Yoshifumi Kawai - How to Use Span in C# to Improve Application Performance
Code Maze - High performance .NET: Building a Redis Clone – skipping strings
Oren Eini - Faster Guid comparisons using Vectors (SIMD) in .NET
Gérald Barré - Using Refit to Consume APIs in C#
Code Maze - Azure AD OAuth client credential flow with custom certificate walk-through
Nicola Delfino - Nondestructive Mutation and Records in C#
Zoran Horvat - Running .NET Core Applications as a Windows Service
Muhammed Saleem - C# vNext - What could come
Steven Giesel - Comparison of FFT Implementations for .NET
Christian Woltering - Challenge: Find the stack smash bug… – answer
Oren Eini - .NET Debugging Tips
Tim Deschryver - Leveraging trimming to make the Microsoft Store faster and reduce its binary size
Sergio Pedri
Como sabemos, ASP.NET Core viene configurado "de serie" para que el middleware que sirve los archivos estáticos (StaticFilesMiddleware) los obtenga desde la carpeta wwwroot. Y ya vimos hace bastante tiempo que si preferíamos utilizar otro nombre para guardar estos archivos, podíamos hacerlo con cierta facilidad.
Pero como a partir de ASP.NET Core 6 el nuevo modelo de configuración cambió varias piezas de sitio, es bueno volver a echar un vistazo y ver cómo podríamos hacerlo en las últimas versiones del framework.
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Desinstala fácilmente versiones antiguas de .NET Core con "dotnet-core-uninstall"
José María Aguilar - Saber si una cadena está vacía usando métodos de extensión (C#/VB.Net)
José María Aguilar
.NET Core / .NET
- Benchmarking to the Bottom — Iterating Arrays in .NET
Stephen Walsh - Improving .NET host error messages and supportability
Richard Lander - Async Enumerable in C# (Part 1)
Mark Heath - How to Implement Retry Logic in C#
Code Maze - Implement IXmlSerializable in a readonly struct
Fons Sonnemans - C# 11 - Top 5 Features in the new C# Version
Nikola M. Zivkovic - Consuming anonymous types with DiagnosticListener in .NET 6
Andrew Lock - High performance .NET: Building a Redis Clone– the wrong optimization path
Oren Eini - How to Call Generic Method Using Reflection in C#
Ahsan Ullah - How to improve Serilog logging in .NET 6 by using Scopes
Davide Bellone - Wrap Event based functions into awaitable Tasks
Steven Giesel - Observing all HTTP requests in a .NET application
Gérald Barré - Write Test Progress To The Console With NUnit
Dawid Sibiński - Speed Up Logging in .NET 6
David McCarter - Using records when implementing the builder pattern in C#
Josef Ottosson
De casualidad me he topado con un interesante cambio que .NET 5 introdujo en los componentes de serialización y deserialización System.Text.Json y que, al menos para mí, pasó totalmente desapercibido en su momento. Por eso, he pensado que quizás sea buena idea dejarlo por aquí, por si hay algún despistado más al que pueda resultar útil.
Como seguro sabéis, al usar los componentes de System.Text.Json para serializar o deserializar una clase, utilizamos el atributo [JsonIgnore] para marcar las propiedades que queremos que sean ignoradas al convertir desde y hacia JSON.
Por ejemplo, dada la siguiente clase:
class User
{
public int Id { get; set; }
public string Email { get; set; }
[JsonIgnore]
public string Token { get; set; }
}
En ella estamos indicando expresamente que la propiedad Token debe ser ignorada, por lo que ésta no aparecerá si serializamos un objeto a JSON:
var user = new User { Id = 42, Email = "john@server.com", Token = "ABCDEF"};
Console.WriteLine(JsonSerializer.Serialize(user));
// Result:
{"Id":42,"Email":"john@server.com"}
Y lo mismo ocurre en sentido contrario:
var jsonStr = "{ \"Id\": 42, \"Email\": \"john@server.com\", \"Token\": \"ABCDEF\"}";
var user = JsonSerializer.Deserialize<User>(jsonStr);
// ¡user.Token es nulo aquí!
