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

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

Como sabemos, para ejecutar cualquier tipo de aplicación .NET Core en un equipo necesitamos tener instalado el runtime o el SDK de la plataforma. Esto es algo que podemos hacer muy fácilmente, simplemente acudiendo a la página oficial de descargas, eligiendo nuestro sistema operativo y siguiendo las instrucciones de instalación.

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 ;)

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

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

Días atrás veíamos cómo utilizar Swashbuckle para generar automáticamente la descripción OpenAPI de APIs creadas con ASP.NET Core MVC y ponerlas a disposición de los consumidores en una ruta específica:
 

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.

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

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

La OpenAPI Specification (OAS) es un estándar abierto para la descripción de APIS REST promovido por la Iniciativa OpenAPI, un consorcio de compañías de primer nivel como Microsoft, Google, IBM, Paypal y otros.

El objetivo de OpenAPI es conseguir una fórmula normalizada para describir las capacidades de un servicio REST, independientemente de los lenguajes o tecnologías con las que sea implementado. Esta descripción, normalmente especificada en formato JSON o YAML, permite a clientes (sean humanos o máquinas) descubrir servicios, comprender sus capacidades y conocer sus detalles de funcionamiento sin necesidad de tener acceso a su código fuente o documentación textual.

Esta especificación formal abre interesantes posibilidades, pues a partir de la definición estandarizada de servicios es posible, entre otros,

• disponer de herramientas de diseño y modelado de servicios,
• generar automáticamente páginas de documentación,
• generar automáticamente código cliente y servidor para dichos servicios para distintos, frameworks y lenguajes de programación,
• generar automáticamente código de testing y validaciones,
• o generar automáticamente mocks de servicios.