Hace unos días, Variable Not Found cumplió dieciséis añitos de vida, una eternidad para este mundo en el que vivimos, donde todo ocurre tan rápido y las cosas cambian a una velocidad de vértigo 😊.
Dieciséis años viviendo algo único. Cada uno de los 1.350 artículos publicados ha sido para mí una increíble oportunidad de mejora y aprendizaje y, con suerte, espero (y confío) haber podido ayudar a alguno de los muchísimos visitantes que durante este periodo han pasado por aquí y me han animado a seguir en la brecha.
Dieciséis años creciendo juntos. Comencé esta aventura con más pelo, mejor vista y bastante menos canas, pero la ilusión de poder escribir sobre lo que me gusta, con el plus de que esto pudiera ser útil para alguien, sigue intacta.
Pero bah, dejémonos de historias sentimentales... como es tradición, veamos cómo ha funcionado el blog durante este año.
Publicado por José M. Aguilar a las 8:05 a. m.
Etiquetas: aniversario, autobombo, blogging
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Describiendo APIs ASP.NET Core con Swagger
José María Aguilar - 32 técnicas de producción de ideas
José María Aguilar
.NET Core / .NET
- Announcing .NET 7 Preview 4
Jeremy Likness - Regular Expression Improvements in .NET 7
Stephen Toub - Using the when Keyword in C# While Handling Exceptions
Code Maze - C# Tip: Convert ExpandoObjects to IDictionary
Davide Bellone - Configuring the Diagnostics Port for dotnet monitor
Mark Downie - Finding “routes” of all-pairs shortest paths with Floyd-Warshall algorithm in C#
Oleg Karasik - The Azure Cosmos DB Journey to .NET 6
Vinod Sridharan - Raw String Literals In C# 11
Wade Gausden - Serializing a Cookie container in C#
Infinite Loop - Override vs New Polymorphism In C# .NET
Wade Gausden - How to Find All Distinct Elements of a Given Integer Array
Jamil Hallal
Solemos pensar que el punto de entrada de una aplicación .NET, ya sea el método estático Main()
del clásico Program.cs
o el nuevo Program.cs
de .NET 6 que utiliza top level statements, es lo primero que se ejecuta en nuestras aplicaciones, en realidad no es así. Hay vida antes de que nuestra aplicación empiece a correr ;)
Aunque obviamente su utilidad es limitada y no es algo que necesitaremos hacer a menudo (o probablemente nunca), es conveniente saber que existen varias formas de insertar código que se ejecute antes que lo que siempre hemos considerado el entry point de nuestra aplicación, y es lo que veremos en este post.
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- ¿Qué es Blazor, eso de lo que todo el mundo habla?
José María Aguilar - Cómo reconocer a los buenos desarrolladores
José María Aguilar
.NET Core / .NET
- Set C# Language Version for All the Projects in a Solution
Bartosz Jarmuż - Getting telemetry data from inside or outside a .NET application
Gérald Barré - How to install and test nuget packages locally
Gary Woodfine - Case Study: Double performance in under 30 minutes
Nik Karpinsky - Techniques and tools to update your C# project - Migrating to nullable reference types
Maarten Balliauw - Using HTTPListener to build a HTTP Server in C#
Nick Charlton - Upgrading a WCF service to .NET 6 with CoreWCF
Mike Rousos - Microsoft Graph's Journey to .NET 6
Joao Paiva - Challenge: Spot the optimization & Challenge: Spot the optimization–solution
Oren Eini - Quickly Map Your NuGet Packages to Sources
Erdembayar Yondon - Generating sortable Guids using NewId
Andrew Lock - One step beyond by using .NET Collections to its fullest
Ioannis Kyriakidis - On awaiting a task with a timeout in C#
Raymond Chen - Forcing HttpClient to use IPv4 or IPv6 addresses
Gérald Barré - Hacking C# - Adjustable arrays
Simon Painter
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- ¿Recomendarías a tu hijo que se dedicase al mundo del desarrollo de software?
José María Aguilar - Incluir recursos estáticos en una Biblioteca de Clases Razor (RCL)
José María Aguilar
.NET Core / .NET
- Dockerfile para .Net 6
Fernando Escolar - CoreWCF 1.0 has been Released, WCF for .NET Core and .NET 5+
Sam Spencer - C++ For C# Developers: Part 1 – Introduction
Jackson Dunstan - How to generate Fake data in C#?
Karthik Chintala - Annotating your C# code - Migrating to nullable reference types
Maarten Balliauw - Create .NET Objects without Calling The Constructor
Khalid Abuhakmeh - Sharing coding style and Roslyn analyzers across projects
Gérald Barré - Different Ways to Implement IHttpClientFactory in .NET Core Apps
Mahesh More - Using User Secrets Configuration In .NET
Wade Gausden - C#: Add event handlers dynamically using reflection
Mike Hadlow
Imaginad que tenemos un controlador MVC como el siguiente:
public class TestController : Controller
{
public IActionResult Add(int a, int b)
{
return Content($"Result: {a + b}");
}
}
Claramente, la acción Add()
retornará la suma de los enteros a
y b
que le llegarán como parámetros de la query string:
GET https://localhost:7182/test/add?a=1&b=2 HTTP/1.1
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Result: 3
Pero, como sabemos, podríamos llamar a la acción sin indicar alguno de esos parámetros, o incluso ninguno de ellos:
Petición | Respuesta |
---|---|
GET /test/add?a=1&b=2 | Result: 3 |
GET /test/add?a=0&b=0 | Result: 0 |
GET /test/add?a=1 | Result: 1 |
GET /test/add | Result: 0 |
Esto es así porque el binder será capaz de poblar correctamente los parámetros a
y b
cuando estén presentes en la cadena de la petición y sean correctos, o les asignará su valor por defecto (0
) cuando no hayan sido suministrados.
Pero dado que el cero es un valor de entrada válido, a priori desde nuestro código no tendríamos forma de distinguir cuándo el parámetro ha sido omitido y cuándo se ha establecido expresamente.
¿Cómo podríamos hacerlo?