Agosto de 2018

Volumen 33, número 8

ASP.NET Core: novedades en ASP.NET Core 2.1

Por Steve Smith

Microsoft ha publicado recientemente ASP.NET Core 2.1 junto con .NET Core 2.1 y Entity Framework (EF) Core 2.1. En combinación, estas versiones ofrecen algunas mejoras en rendimiento, así como características adicionales para los desarrolladores de .NET Core. Microsoft también ofrece a largo plazo soporte técnico (LTS) con esta versión, lo que significa que seguirá siendo compatible durante tres años. En este artículo se proporciona información general de las mejoras de ASP.NET Core 2.1. Para obtener más información sobre novedades de EF Core 2.1, revise la columna de puntos de datos de este mes, Julie Lerman, "Deep Dive en EF Core HasData propagación" y su columna del mes pasado (msdn.com/magazine/mt847184) que se adentra en el nuevo EF Core 2.1 consultar la característica de tipo, que le permite obtener más fácilmente sin necesidad de true entidades con propiedades de clave para consumir los resultados de consulta una base de datos.

Mejoras de páginas de Razor

Comenzaré por hablar sobre las mejoras en las páginas de Razor, una nueva característica introducida en ASP.NET Core 2.0 que escribí acerca de la edición de septiembre de 2017 (msdn.com/magazine/mt842512). Versión 2.1 agrega algunas características que no se incluyeron en la versión 2.0, como la compatibilidad con carpetas específicas de las páginas para buscar recursos compartidos. Los recursos compartidos más comunes son parciales y los archivos de diseño. De forma predeterminada, estas se encontraban en la carpeta/páginas raíz en ASP.NET Core 2.0, aunque ASP.NET Core MVC sería detectarlos si se encontraran en una carpeta /Views/Shared. En la versión 2.1, las páginas de Razor ahora busca estos archivos compartidos, busque en las siguientes ubicaciones (en orden):

  1. La carpeta actual de páginas
  2. / / Compartir páginas
  3. / Vistas/Shared

Esto le permite reemplazar fácilmente recursos compartidos que desee, pero si va a agregar las páginas de Razor a una aplicación existente basada en MVC, aún puede aprovechar los recursos compartidos existentes que tiene en su carpeta /Views/Shared.

Otra característica que falta cuando se publicó inicialmente las páginas de Razor era la posibilidad de áreas. Con ASP.NET Core 2.1, ahora puede agregar una carpeta/páginas con las páginas de Razor en cualquier área que se encuentra en la carpeta /Areas de la aplicación ASP.NET Core. Microsoft también ha actualizado la plantilla de aplicación Web de Visual Studio de forma predeterminada para usar las áreas de funcionalidad de identidad cuando se elige "cuentas de usuario individuales".

Juntas, estas características facilitan mucho más fácil organizar las páginas de Razor en el sistema del proyecto.

Bibliotecas compartidas de Razor

Otra nueva característica de 2.1 es soporte para cargar activos de Razor de otras bibliotecas o paquetes. Aplicaciones independientes de ASP.NET Core con frecuencia compartan recursos comunes, como las características de identidad (inicio de sesión, registro, ¿ha olvidado contraseña etc.). Normalmente, estas características comunes dieron lugar a una gran cantidad de código duplicado entre los proyectos individuales, dando lugar a un aumento deuda técnica. La nueva biblioteca de clases de Razor (RCL) característica admite la generación de archivos de Razor e implementarlos como los proyectos asociados o paquetes de NuGet que puede usar cualquier número de aplicaciones de ASP.NET Core.

Con la adición de esta característica, el compilador generará activos de Razor, busca automáticamente los recursos relacionados en los paquetes y bibliotecas que se hace referencia. Anteriormente, los activos de Razor no se generaron hasta después de que se han implementado y se solicita. Compilación de Razor se integra ASP.NET Core 2.1 en el proceso de compilación, que también tiene como resultado tiempos más rápidos de inicio de aplicación.

Activos de Razor en RCLs pueden reemplazarse por lo que si usa para compartir recursos comunes entre proyectos, no perderá la capacidad para personalizar algunos aspectos en cada proyecto. RCLs brillan para las aplicaciones cuestiones transversales como la exploración, diseño y la autenticación. De hecho, la característica integrada de ASP.NET Core Identity es capaz de aprovechar esta compatibilidad a convertirse en reutilizable más entre proyectos, también.

Actualizaciones de la plantilla de proyecto

La plantilla de proyecto de aplicación Web predeterminada incluye algunos cambios no anteriormente mencionados. El cuadro de diálogo nuevo proyecto ahora incluye una casilla de verificación para especificar si desea exigir HTTPS. Nueva compatibilidad para el Reglamento General de protección de datos (RGPD) se incluye de forma predeterminada, por lo que los proyectos ahora incluyen páginas de privacidad de forma predeterminada y parciales de Razor de consentimiento de cookie. Tenga en cuenta que estos documentos son simplemente los marcadores de posición, es su responsabilidad para agregar directiva real de su organización. Figura 1 muestra un nuevo proyecto de ASP.NET Core 2.1, que se ha configurado para usar la identidad para las cuentas de usuario individuales.

Nueva estructura de proyecto de aplicación Web en ASP.NET Core 2.1
Figura 1 nueva estructura de proyecto de Web Application en ASP.NET Core 2.1

Identidad como un complemento

Si desea aprovechar la funcionalidad de ASP.NET Core Identity en la aplicación antes de la versión 2.1, por lo general tenía que tomar la decisión para agregar compatibilidad para él al crear el proyecto de aplicación Web. Si desea agregar compatibilidad con identidad más adelante, normalmente el proceso sería crear un nuevo proyecto de aplicación Web con el soporte técnico adecuado (por ejemplo, "cuentas de usuario individuales") y, a continuación, copie los archivos de la nueva aplicación en la aplicación existente. Esto no es una solución ideal.

Siempre era un reto difícil técnico para ASP.NET Core (y ASP.NET, demasiado) para admitir agregar compatibilidad con identidad a una aplicación existente, en parte porque esta compatibilidad incluye activos Razor front-end que no se pudo empaquetados por separado e implementar nuevos recursos en un podría producirse un error de aplicación existente para un sinnúmero de motivos. Con la adición de compatibilidad RCL, agregar que identidad a una aplicación existente se vuelve mucho más sencilla, como el proceso ya no necesita agregar nuevos archivos de Razor en la aplicación existente.

Puede usar la compatibilidad con la técnica scaffolding en Visual Studio para agregar la identidad para las aplicaciones existentes. Nuevas aplicaciones creadas con las últimas plantillas aprovechará recursos compartidos de Razor en lugar de incluidos relacionados con la identidad páginas o vistas en el propio proyecto. La ventaja de este enfoque es menos archivos reutilizable en los proyectos nuevos, pero sin pérdida de funcionalidad o la capacidad de personalizar el comportamiento. Se vio en figura 1 que de forma predeterminada la compatibilidad con identidad solo agrega un área con un archivo único _ViewStart.cshtml en ella. Puede personalizar el comportamiento de determinados archivos con el botón secundario en el proyecto, haga clic en Agregar | Nuevo elemento de scaffolding y, a continuación, elegir la identidad. Seleccione las páginas que desea aplicar la técnica scaffolding y especificar la clase DbContext y cualquier otra opción.

Verá cómo voy a personalizar estos archivos cuando me pongo a SignalR.

Compatibilidad con HTTPS mejorada

Si ya no usa HTTPS para las aplicaciones Web, probablemente debería. Los motores de búsqueda y los exploradores son ahora activamente promover sitios que usan HTTPS y aquellas que no tratar como potencialmente inseguros. GDPR requiere que los sitios usan HTTPS para proteger la privacidad del usuario. ASP.NET Core 2.1 fortalecen la compatibilidad para desarrollar y probar aplicaciones mediante HTTPS, así como convertir mucho más fácil de usar HTTPS localmente al crear aplicaciones.

Después de instalar el SDK de .NET Core 2.1, la primera vez que se ejecute, instalará un certificado de desarrollo. Puede administrar este certificado con la nueva herramienta dev-certs dotnet, que se instala con el SDK. Una vez que el certificado de desarrollo es de confianza, podrá desarrollar y probar sus aplicaciones de ASP.NET Core 2.1 localmente mediante HTTPS como el protocolo predeterminado, más detenidamente la creación de reflejo su entorno de producción (que por supuesto que usa HTTPS).

La aplicación puede mejorar aún más su seguridad mediante señales a los exploradores que admite seguridad de transporte estricto (HSTS) de HTTP. HSTS ayuda a evitar ciertos tipos de ataques, como ataques de "tipo man in the middle", de señalización para exploradores que todas las respuestas para una determinada solicitud deben utilizar conexiones HTTPS en lugar de HTTP sin formato. Sin HSTS, incluso una página que se envía a través de HTTPS puede incluir recursos que aún utilizan HTTP. Estos recursos podrían ser fácilmente reemplazados o modificados por los enrutadores entre el usuario y los servidores que hospedan el contenido, ya que están desprotegidos por el cifrado. HSTS impide que este vector de ataque.

HSTS se implementa con un encabezado de respuesta en la respuesta HTTPS del recurso original. Por ejemplo:

Strict-Transport-Security: max-age=16070400; includeSubDomains

HSTS está habilitada para las aplicaciones de ASP.NET Core con middleware, configurado de forma predeterminada en el archivo de la plantilla aplicación Startup.cs. No se recomienda para usar HSTS en localhost, por lo que el comportamiento predeterminado solo incluye el middleware cuando el proyecto se está ejecutando en un entorno de producción.

Además de HSTS, también puede requerir HTTPS para una aplicación mediante el middleware UseHttpsRedirection nuevo. En su forma más simple, habilita agregando la línea siguiente a su método Configure en Startup.cs:

App.UseHttpsRedirection();

Microsoft recomienda ahora esto para todas las aplicaciones de ASP.NET Core, y es el valor predeterminado en las plantillas de aplicación Web. Este middleware le redireccionará automáticamente a las solicitudes que provengan HTTP a HTTPS. Usa las convenciones para detectar el puerto HTTPS adecuado, suponiendo que sólo uno está usando la aplicación. Como alternativa, puede configurar estableciendo la variable de entorno ASPNETCORE_HTTPS_PORT (o clave de configuración http_port) o especificando opciones en el código en ConfigureServices:

services.AddHttpsRedirection(options => options.HttpsPort = 5555);

Plantillas SPA actualizada

Se actualizaron las plantillas de aplicación para aplicaciones de página única (SPA) para usar los enfoques recomendados más recientes para las aplicaciones de Angular y React. En concreto, la plantilla de Angular se basa ahora en la interfaz de línea de comandos (CLI) de Angular, y las plantillas de React se basan en crear-react-app (CRA). Estos marcos SPA distribuyen las actualizaciones con frecuencia, para actualizar las plantillas integradas para los enfoques más recientes le ayuda a asegurarse de nuevas aplicaciones compiladas con ellos usará los procedimientos recomendados actuales para cada marco de trabajo asociado.

SignalR

SignalR es una conocida biblioteca que resulta muy sencillo agregar funcionalidad Web en tiempo real a las aplicaciones de ASP.NET. ASP.NET Core SignalR es una versión nueva de SignalR que se incluye con ASP.NET Core 2.1. Ofrece una serie de mejoras con respecto a versiones anteriores:

  • Ninguna dependencia de cliente de jQuery
  • Protocolo binario de MessagePack
  • En función de Microsoft.AspNetCore.Sockets (no Http)
  • Admite varios formatos (desde el mismo punto de conexión)

Los componentes de servidor de SignalR se incluyen en el paquete Microsoft.AspNetCore.SignalR NuGet. Este paquete se incluye en el metapaquete Microsoft.AspNetCore.App, lo que normalmente no es necesario agregar por separado a su proyecto de ASP.NET Core (suponiendo que se hace referencia Microsoft.AspNetCore.App versión 2.1 o posterior). SignalR es compatible con varios clientes, incluidos JavaScript para páginas Web y un cliente de .NET para aplicaciones. NET. La manera recomendada para agregar al cliente de JavaScript a su proyecto es a través de npm. Suponiendo que tiene instalado npm, puede ejecutar los comandos siguientes para agregar al cliente a su proyecto:

npm init –y
npm install @aspnet/signalr

El primer comando Inicializa un archivo packages.config para el proyecto, solo deberá ejecutar este comando si ya no usa npm. El segundo comando descarga al cliente de JavaScript de SignalR a la carpeta node_modules. Se deberá copiar el archivo signalr.js desde node_modules a una ubicación adecuada en la carpeta wwwroot de la aplicación ASP.NET Core con el fin de hacer referencia a él desde su aplicación.

Demostración de SignalR: Notificaciones del sistema

Para demostrar lo fácil que es configurar la aplicación con SignalR, mientras también se muestra cómo personalizar el comportamiento del nuevo paquete de identidad, he creado una demostración simple. Aparecerá una notificación en el explorador siempre que un usuario registra o firma dentro o fuera de la aplicación. Esta notificación debe aparecer en cualquier lugar en el sitio, así que voy a modificar el archivo _Layout.cshtml para incluir los scripts del lado cliente necesarios. Agregue lo siguiente a la parte inferior del archivo _Layout.cshtml:

<script src="//cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/js/
  toastr.min.js"></script>
<script src="~/lib/signalr/signalr.js"></script>
<script src="~/js/site.js" asp-append-version="true"></script>

La primera referencia es una biblioteca de notificación simple denominada toastr que usaré para mostrar las notificaciones. El segundo es el archivo signalr.js copiado node_modules en la carpeta wwwroot/lib/signalr de la aplicación. El último es el archivo site.js existente que se crea como parte de un nuevo proyecto de ASP.NET Core. Es importante el orden de estas secuencias de comandos.

El paso siguiente es modificar site.js para agregar el código JavaScript necesario para mostrar los mensajes cuando se recibe una solicitud desde el servidor. Hay tres pasos implicados en este proceso. En primer lugar, debe ser crear una conexión, utilizando el signalR.HubConnectionBuilder. Este tipo usa el patrón de diseño de generador para configurar la conexión con todos los parámetros necesarios y, a continuación, la conexión se devuelve desde el método de compilación. A continuación, configure los controladores de mensajes utilizando el método .on en la conexión. Cree un controlador con nombre para cada comportamiento que desea que el servidor para poder iniciar. Por último, la conexión se inicia mediante una llamada a su método de inicio:

const userUpdatesConnection = new signalR.HubConnectionBuilder()
  .withUrl("/userUpdates")
  .build();
userUpdatesConnection.on("ReceiveSignIn", (user) => {
  toastr.options.escapeHtml = true;
  const message = user + " logged in.";
  toastr.info(message, "New Login!");
});
// Additional handlers omitted
userUpdatesConnection.start().catch(err => console.error(err.toString()));

Este código se ejecutará en todas las páginas que usa _Layout.cshtml. Ahora configuraré el extremo de servidor de la conexión, a partir de Startup.cs. Deberá modificar el método ConfigureServices para incluir SignalR (normalmente después de llamar a servicios. AddMvc):

services.AddSignalR();

A continuación, en el método Configure, deberá configurar las rutas de SignalR, justo antes de llamar a la aplicación. UseMvc:

app.UseSignalR(routes =>
{
  routes.MapHub<UsersHub>("/userUpdates");
});
app.UseMvc();

Ahora es momento de agregar la clase UsersHub que hace referencia anteriormente. Esta clase se puede colocar en una carpeta de concentradores, que es un enfoque común, o piensa sobre el uso de más de un enfoque de la carpeta de características, tal como describí en mi artículo de septiembre de 2016, "Sectores de características para ASP.NET Core MVC" (msdn.com/magazine/mt763233) y poner el concentrador con los páginas y controladores con el que funciona. En cualquier caso, para este escenario, porque el cliente no está realizando llamadas al concentrador, la clase no necesita una implementación real. Basta con que heredan de Microsoft.AspNetCore.SignalR.Hub:

public class UsersHub : Hub
{
}

Por último, utilizar el concentrador para comunicarse con clientes conectados desde cualquier parte en la aplicación, usar inserción de dependencias para insertar IHubContext < THub > en la clase que lo necesite. En este caso, las clases PageModel para inicio de sesión, cierre de sesión y registrar cada tienen una instancia de IHubContext < UsersHub > insertado en sus constructores.

Para enviar un mensaje, utilice la instancia de HubContext para tener acceso a su propiedad de los clientes y enviar un mensaje a un controlador con nombre determinado. Figura 2 muestra la implementación para el método de cierre de sesión PageModel OnPost.

Figura 2 implementación del método de cierre de sesión PageModel OnPost

public async Task<IActionResult> OnPost(string returnUrl = null)
{
  string username = User.Identity.Name;
  await _signInManager.SignOutAsync();
  _logger.LogInformation("User logged out.");
  await _usersHubContext.Clients.All.SendAsync("ReceiveSignOut", username);
  if (returnUrl != null)
  {
    return LocalRedirect(returnUrl);
  }
  else
  {
    return Page();
  }
}

Con estas piezas en su lugar, puede ejecutar la aplicación y abrir varios exploradores diferentes para mostrar la aplicación. En uno, registre e inicie sesión dentro y fuera de la aplicación. Debería ver las notificaciones que aparecen en los otros exploradores. La mitad izquierda del figura 3 muestra las notificaciones que aparecen en un explorador Chrome, una vez que un usuario haya iniciado dentro y fuera de un explorador Edge a la derecha.

SignalR de ASP.NET Core enviar notificaciones de servidor a los exploradores conectados
Figura 3 ASP.NET Core SignalR enviar notificaciones de servidor a los exploradores conectados

Mejoras de prueba de integración

ASP.NET Core tiene excelente compatibilidad para la integración de pruebas desde la versión 1.0 de la pila completo en memoria. Sin embargo, una cosa que requiere algún programa de instalación personalizado para lograr configurar TestServer con la ruta de acceso raíz de contenido apropiado, para que encontró correctamente los recursos, como las vistas dentro de la aplicación Web. ASP.NET Core 2.1 incorpora a un nuevo tipo, WebApplicationFactory < T >, lo que facilita la creación de un TestServer y un HttpClient que se conecta a él. Para utilizar el generador dentro de una clase de prueba de Xunit, implementa la interfaz de IClassFixture < WebApplicationFactory < Inicio >>, donde inicio es el punto de entrada para la aplicación de ASP.NET Core que desea probar. A continuación, en el constructor de clase, insertar un WebApplicationFactory < Inicio > y use su método CreateClient para obtener una instancia de un cliente. En las pruebas, a continuación, puede usar el cliente para realizar solicitudes a la aplicación y compruebe que se devuelve la respuesta correcta, así:

[Fact]
public async Task Get_HomePageReturnSuccessAndCorrectContentType()
{
  var response = await _client.GetAsync("/");
  response.EnsureSuccessStatusCode(); // Status Code 200-299
  Assert.Equal("text/html; charset=utf-8",
    response.Content.Headers.ContentType.ToString());
}

Si necesita personalizar la aplicación para las pruebas, como el cambio que se usan los servicios o agregar datos de inicialización que se usará para realizar pruebas, puede heredar de WebApplicationFactory < T > y, a continuación, usar el generador personalizado en las pruebas.

Mejoras adicionales

Esta versión también ve mejoras en otras partes de ASP.NET Core 2.1, incluido el servidor Kestrel integrado. Kestrel ahora usa sockets administrados para su capa de transporte predeterminado, en lugar de libuv. Este cambio debe ser transparente, pero si lo hace que los problemas, los desarrolladores pueden configurar todavía libuv para su uso con Kestrel.

Otra novedad incorporada en el componente de hospedaje de ASP.NET Core es del tipo HostBuilder, que se pueden utilizar para configurar elementos Web que no son de un host. HostBuilder es muy similar a WebHostBuilder existente, pero no le permiten especificar una clase de inicio de un proyecto Web. Se ha diseñado para permitirle configurar preocupaciones comunes como inserción de dependencias, configuración y registro para escenarios sin Web como aplicaciones de consola o los servicios hospedados.

Por último, si va a escribir los puntos de conexión de API en su aplicación ASP.NET Core, se puede aprovechar algunas mejoras que se agregaron en 2.1. En primer lugar, puede agregar el atributo [ApiController] a cualquiera de los controladores que exponen las API. Esto agrega una serie de características para puntos de conexión definidos en estos controladores, tales como:

  • Errores de validación del modelo devolverá automáticamente BadRequest(ModelState)
  • Orígenes de enlace (por ejemplo, [FromBody]) se deduce automáticamente para los parámetros de acción
  • Cargas de archivos mediante [FromForm] automáticamente inferir el tipo de contenido multipart/form-data
  • Es necesario el enrutamiento mediante atributos

Otra adición es un nuevo tipo de valor devuelto, ActionResult < T >. Este tipo de valor devuelto se utiliza en lugar de IActionResult y permite que la información de tipo que se incluirán en la firma del método. Herramientas como Swashbuckle pueden usar esta información para generar documentación de OpenAPI/Swagger. Sin este tipo de valor devuelto, deberá anotar métodos que devuelven simplemente IActionResult con el atributo [ProducesResponseType] para exponer esta información.

Pasos siguientes

Si ya no usa ASP.NET Core 2.1, recomienda actualizar tan pronto como sea posible. Puede obtener el SDK en microsoft.com/net/download/windows o ejecutar las herramientas de Docker desde una de las imágenes en dockr.ly/2MAaiEF. El código fuente actualizado de este ejemplo está disponible en bit.ly/2JXdHeV.


Steve Smithes un profesor independiente, profesor y consultor. Tiene un blog en ardalis.com y se proporcionan sugerencias para desarrolladores a través de correo electrónico y podcast en WeeklyDevTips.com. Consulte sus cursos de Pluralsight para obtener información sobre cómo desarrollar limpiador, aplicaciones de mayor calidad. Puede seguirle en Twitter: @ardalis.


Discuta sobre este artículo en el foro de MSDN Magazine