Guía de uso

Microsoft.AspNetCore.SystemWebAdapters proporciona una capa de emulación para imitar el comportamiento de ASP.NET Framework en ASP.NET Core. A continuación se muestran algunas de las directrices para algunas de las consideraciones al usarlas:

Duración de HttpContext

Los adaptadores están respaldados por HttpContext que no se puede usar más allá de la duración de una solicitud. Por lo tanto, cuando HttpContext se ejecuta en ASP.NET Core tampoco se puede usar después de una solicitud, mientras que en ASP.NET Framework funcionaría a veces. Un ObjectDisposedException será lanzado en los casos en los que se usa más allá de un final de solicitud.

Recomendación: almacene los valores necesarios en un POCO y aférrese a eso.

Conversión a HttpContext

Hay dos maneras de convertir un HttpContext en un HttpContext:

• Conversión implícita
• Uso del constructor

Recomendación: En la mayoría de los casos, se debe preferir la conversión implícita, ya que almacenará en la caché la instancia creada y garantizará solo una única HttpContext por solicitud.

CurrentCulture no se establece de forma predeterminada

En ASP.NET Framework, CurrentCulture se estableció para una solicitud, pero esto no se realiza automáticamente en ASP.NET Core. En su lugar, debe agregar el middleware adecuado a la canalización.

Recomendación: consulte Localización de ASP.NET Core para obtener más información sobre cómo habilitar esta opción.

La manera más sencilla de habilitar esto con un comportamiento similar a ASP.NET Framework sería agregar lo siguiente a la canalización:

app.UseRequestLocalization();

CurrentPrincipal

En ASP.NET Framework, CurrentPrincipal y Current se establecerían en el usuario actual. Esto no es posible en ASP.NET Core estándar. Esta compatibilidad se puede lograr con estos adaptadores agregando ISetThreadCurrentPrincipal al punto de conexión (disponible para los controladores a través de SetThreadCurrentPrincipalAttribute). Sin embargo, solo se debe usar si no se puede refactorizar el código para quitar el uso.

Recomendación: Si es posible, use la propiedad User o User , en su lugar, pasándola al sitio de llamada. Si no es posible, habilite la configuración del usuario actual y considere también la posibilidad de establecer la solicitud para que sea un único subproceso lógico (consulte a continuación para obtener más información).

El subproceso de solicitud no existe en ASP.NET Core

En ASP.NET Framework, una solicitud tenía afinidad de subproceso y Current solo estaría disponible si se encuentra en ese subproceso. ASP.NET Core no tiene esta garantía, por lo que Current estará disponible en el mismo contexto asincrónico, pero no se realizan garantías sobre los subprocesos.

Recomendación: Si lee o escribe en HttpContext, debe asegurarse de que lo está haciendo en un solo subproceso. Puede forzar que una solicitud nunca se ejecute simultáneamente en cualquier contexto asincrónico estableciendo ISingleThreadedRequestMetadata. Esto tendrá implicaciones de rendimiento y solo se debe usar si no puede refactorizar el uso para garantizar el acceso no simultáneo. Hay una implementación disponible para agregar a controladores con SingleThreadedRequestAttribute:

[SingleThreadedRequest]
public class SomeController : Controller
{
    ...
} 

Request es posible que deba ser almacenado en búfer antes

De forma predeterminada, la solicitud entrante no siempre se puede buscar ni está totalmente disponible. Para obtener el comportamiento que se ve en .NET Framework, puede optar por almacenar previamente el flujo de entrada en el búfer. Esto leerá completamente la secuencia entrante y la almacenará en el búfer en memoria o disco (según la configuración).

Recomendación: esto se puede habilitar aplicando los metadatos de punto de conexión que implementan la interfaz IPreBufferRequestStreamMetadata. Esto está disponible como atributo PreBufferRequestStreamAttribute que se puede aplicar a controladores o métodos.

Para habilitarlo en todos los puntos de conexión de MVC, hay un método de extensión que se puede usar de la siguiente manera:

app.MapDefaultControllerRoute()
    .PreBufferRequestStream();

Response puede requerir almacenamiento en búfer

Algunas API en Response requieren que el flujo de salida esté almacenado en búfer, por ejemplo Output, End(), Clear()y SuppressContent.

Recomendación: para admitir el comportamiento de Response que requiere almacenar en búfer la respuesta antes de enviarla, los puntos de conexión deben participar en él con metadatos de punto de conexión que implementen IBufferResponseStreamMetadata.

Para habilitarlo en todos los puntos de conexión de MVC, hay un método de extensión que se puede usar de la siguiente manera:

app.MapDefaultControllerRoute()
    .BufferResponseStream();

Estado de la sesión compartido

Para admitir Session, los puntos de conexión deben participar en él a través de metadatos que implementen ISessionMetadata.

Recomendación: Para habilitarlo en todos los puntos de conexión de MVC, hay un método de extensión que se puede usar de la siguiente manera:

app.MapDefaultControllerRoute()
    .RequireSystemWebAdapterSession();

Esto también requiere alguna implementación de un almacén de sesiones. Para obtener más información sobre las opciones de esto, consulte aquí.

La sesión remota expone un punto de conexión adicional para la aplicación

La compatibilidad con sesiones remotas expone un punto de conexión que permite a la aplicación principal recuperar información de la sesión. Esto puede hacer que exista una solicitud potencial de larga duración entre la aplicación Core y la aplicación Framework, pero agotará el tiempo de espera con la solicitud actual o el tiempo de espera de la sesión (de forma predeterminada es de 20 minutos).

Recomendación: asegúrese de que la clave de API usada es una segura y de que la conexión con la aplicación Framework se realiza a través de SSL.

Los directorios virtuales deben ser idénticos para las aplicaciones Framework y Core

La configuración del directorio virtual se usa para la generación de rutas, la autorización y otros servicios dentro del sistema. En este momento, no se ha encontrado ningún método confiable para habilitar directorios virtuales diferentes debido a cómo funciona ASP.NET Framework.

Recomendación: asegúrese de que las dos aplicaciones están en sitios diferentes (hosts y/o puertos) con el mismo diseño de directorio virtual o aplicación.