Hoy vamos a hablar de una de eso pequeños descubrimientos: el rutado dinámico de controladores. Introducido en ASP.NET Core 3, se trata de una característica que no ha sido especialmente publicitada ni comentada, pero puede ser de utilidad en algunas ocasiones, pues permite interferir en la forma de interpretar las rutas de las peticiones entrantes con objeto de decidir en cada caso cómo deben ser procesadas.
Publicado por José M. Aguilar a las 8:05 a. m.
Etiquetas: aspnetcore, aspnetcoremvc
Por si te lo perdiste...
- Ámbito local implícito en sentencias using de C# 8
José María Aguilar - Cacheo de porciones de vistas en ASP.NET Core MVC
José María Aguilar
.NET Core / .NET
- Escribiendo código de alto rendimiento en .Net Core
Jorge Turrado - Announcing .NET Interactive - Try .NET includes .NET Notebooks and more
Scott Hanselman - C# to C# Communication: REST, gRPC and everything in between
Michael Shpilt - Producing Multiple Related NuGet Packages from a Single Git Repo
Mark Heath - How to protect against XML vulnerabilities in .NET
Gérald Barré - How to run ASP.NET Core as a service on Linux (RHEL)
Niels Swimberghe - How to send emails from C#/.NET
Thomas Ardal - Binding Redirects
Nick Craver - Save Your C# Keystrokes With Tuples
Khalid Abuhakmeh - Get started with .NET Generic Host » André Snede Kock
André Snede Kock - Simplifying Parameter Null and Other Checks with the GuardClauses Library
Jason Roberts - Iterators in C#, IEnumerable<T>, and IAsyncEnumerable<T>
Spencer Schneidenbach - The Maybe Monad in C#: More methods
Yacoub Massad - The most dangerous constructor in .NET » André Snede Kock
André Snede Kock - Clean up your .NET with the Dispose Pattern
Nick Proud - Creating .NET Core global tools on macOS
Sayed Hashimi - Mono: From Xamarin to WebAssembly, Blazor, and .NET 5
Arthur Casals
El hecho de que en el equipo destino esté preinstalado el runtime es muy interesante, entre otras cosas porque permite asegurar de antemano que en él se encontrarán todas las dependencias (frameworks, bibliotecas, paquetes, metapaquetes) necesarios para una correcta ejecución. Por tanto, para distribuir nuestra aplicación sólo debemos generar lo relativo a nuestro código, el resto ya estará allí.
Esta forma de publicar aplicaciones se denomina framework-dependent, pues dependen de que determinados componentes del framework estén instalado en el destino.Por ejemplo, el paquete de publicación de una aplicación de consola prácticamente vacía, que únicamente muestra el mensaje "Hello world!", ocuparía solo 175K:
D:\MyConsoleApp\output>dir
El volumen de la unidad D es Datos
El número de serie del volumen es: 8CBC-81E3
Directorio de D:\MyConsoleApp\output
09/02/2020 18:47 <DIR> .
09/02/2020 18:47 <DIR> ..
09/02/2020 18:46 428 MyConsoleApp.deps.json
09/02/2020 18:46 4.608 MyConsoleApp.dll
09/02/2020 18:46 169.984 MyConsoleApp.exe
09/02/2020 18:46 668 MyConsoleApp.pdb
09/02/2020 18:46 154 MyConsoleApp.runtimeconfig.json
5 archivos 175.842 bytes
2 dirs 463.058.874.368 bytes libres
D:\MyConsoleApp\output>_
Otra ventaja de este tipo de distribución es que es cross platform pura, es decir, podemos copiar los archivos a cualquiera de los sistemas operativos soportados y, siempre que dispongan del runtime, nuestra aplicación podrá correr sobre ellos sin problema.Y todo esto está muy bien, pero, ¿qué pasa si quiero crear una aplicación portable, de forma que pueda distribuirla y ejecutarla sin necesidad de que el equipo destino tenga nada preinstalado?
Pues eso es lo que veremos en este post ;)
Por si te lo perdiste...
- Constructores con parámetros en entidades EF Core
José María Aguilar - Creación de enlaces con tag helpers de ASP.NET Core MVC
José María Aguilar
.NET Core / .NET
- C#: Equals y ref structs
Eduard Tomás - .NET Interactive is here! | .NET Notebooks Preview 2
Maria Naggaga - Creating Certificates in .NET Core for Vue.js development using HTTPS
Damien Bowden - NAudio 1.10 released with .NET Core 3 support
Mark Heath - Non-exceptional averages
Mark Seemann - The design and implementation of a better ThreadLocal<T>
Oren Eini - Check if the current user is an administrator
Gérald Barré - Tips & tricks for unit testing in .NET Core 3: Using and mocking ISystemClock instead of using DateTime & Checking matching and non matching arguments on ILogger & Mocking IHttpContextAccessor
Anthony Giretti - C# how to convert a string to int
Thomas Ardal - C# 8.0 Using Declaration
Dirk Strauss - Hosting your own NuGet Server and Feed for build artifacts with BaGet
Scott Hanselman - C# 8.0 - What C# version does my App use?
Dirk Strauss - GC Handles & Garbage Collection at Food Courts
Maoni Stephens
En este post vamos a ver un par de formas de sacar provecho de esta descripción:
- En primer lugar, usaremos Swagger UI para generar un sitio web interactivo de documentación y pruebas de nuestra API.
- Después, veremos cómo generar desde Visual Studio código cliente para acceder a la API.
Publicado por José M. Aguilar a las 8:05 a. m.
Etiquetas: aspnetcore, aspnetcoremvc, openapi, swagger, webapi
Por si te lo perdiste...
- Inyección de dependencias en ASP.NET Core
José María Aguilar - Backing fields en Entity Framework Core
José María Aguilar
.NET Core / .NET
-
Cómo hacer mock de ILogger en .Net Core 3.x durante las pruebas
Jorge Turrado
-
NetCore 3 - NativeLibrary: ¡p/invoke a tope!
Eduard Tomás
-
Autofac 5.0 Released
Travis Illig
-
Prevent Zip bombs in .NET Prevent Zip Slip in .NET
Gérald Barré
-
Dynamically Loading Types in .NET Core with a Custom Assembly Load Context
Jeremy Clark
-
TraceProcessor 0.3.0
David Matson
-
Top 10 .NET Core Libraries Every Web Developer Should Know
Nagaraj Marisamy
-
Optimizing string.Count all the way from LINQ to hardware accelerated vectorized instructions
Sergio Pedri
-
C# Futures: Primary Constructors
Jonathan Allen
-
C# Coding Standards
Jesse Liberty
-
Deserializing JSON into polymorphic classes with System.Text.Json
Maarten Balliauw
- Dependency injection in .net core console application
Pradeep Loganathan