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.

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

Por si te lo perdiste...

• Crear proyectos usando versiones específicas del SDK de .NET Core
  José María Aguilar
• Tag helpers en ASP.NET Core MVC: Introducción
  José María Aguilar

.NET Core / .NET

• Windows Forms en .NET Core: Controles inexistentes y cómo sustituirlos
  CampusMVP
• WPF y netcore3 con custom host
  Eduard Tomás
• Using Local Functions to Replace Comments & Refactoring Code to Use C# Local Functions
  Jason Roberts
• Behind the compiler: 20 examples of C# code before and after compiling
  Gunnar Peipman
• Avoiding the Debugger with Better Logging
  K. Scott Allen
• .NET everywhere apparently also means Windows 3.11 and DOS
  Scott Hanselman
• Generating Mazes in a Browser
  Jeremy Clark
• Getting the Most Out of Application Insights for .NET (Core) Apps
  Dave Paquette
• Developing Mobile Applications in .NET
  Damir Arh
• A Custom Renderer Extension for Markdig
  K. Scott Allen
• C# Futures: Covariant Return Types
  Jonathan Allen

ASP.NET Core / ASP.NET

• Using NSwag to Generate Blazor Server Client for an ASP.NET Core 3.1 API
  Eric L. Anderson
• Deploying Blazor apps to Azure Storage account
  Anuraj Parameswaran
• The Future of Blazor is Native Apps
  Matthew MacDonald
• 6 Blazor component libraries to speed up your development
  Jon Hilton
• Scaffolding Syncfusion Controls in ASP.NET Core Applications
  Kannan
• Cookies and Consent in ASP .NET Core 3.1
  Shahed Chowdhuri
• User Registration with ASP.NET Core Identity
  Marinko Spasojevic
• Excluding health check endpoints from Serilog request logging: Using Serilog.AspNetCore in ASP.NET Core 3.0
  Andrew Lock
• Check and log multiple registrations of a same service in ASP.NET Core 3.1 & Remove unwanted instances from ServiceCollection in ASP.NET Core 3.1
  Anthony Giretti
• Blazor State Management
  Jeremy Likness
• Globally Require Authenticated Users By Default Using Fallback Policies in ASP.NET Core
  Scott Sauber
• Sharing Data and Splitting Components in Blazor
  Peter Vogel
• Understanding how to port your ASP.NET web apps to ASP.NET Core
  Mike Finley