Diretriz de uso

Microsoft.AspNetCore.SystemWebAdapters fornece uma camada de emulação para imitar o comportamento do ASP.NET Framework no ASP.NET Core. Abaixo estão algumas diretrizes para algumas das considerações ao usá-las:

HttpContext tempo de vida

Os adaptadores são apoiados pelos HttpContext que não podem ser usados após o tempo de vida de uma solicitação. Portanto, HttpContext quando executado no ASP.NET Core, também não pode ser usado após uma solicitação, enquanto no ASP.NET Framework ele funcionaria às vezes. Um ObjectDisposedException será lançado nos casos em que ele é usado após o término de uma solicitação.

Recomendação: armazene os valores necessários em um POCO e mantenha isso.

Conversão para HttpContext

Há duas maneiras de converter um HttpContext em um HttpContext:

• Conversão implícita
• Uso do construtor

Recomendação: para a maioria dos casos, a conversão implícita deve ser preferencial, pois isso armazenará em cache a instância criada e garantirá apenas um único HttpContext por solicitação.

CurrentCulture não é definido por padrão

No ASP.NET Framework, CurrentCulture foi definido para uma solicitação, mas isso não é feito automaticamente no ASP.NET Core. Em vez disso, você deve adicionar o middleware apropriado ao pipeline.

Recomendação: consulte Localização ASP.NET Core para obter detalhes sobre como habilitar isso.

A maneira mais simples de habilitar isso com um comportamento semelhante ao ASP.NET Framework seria adicionar o seguinte ao pipeline:

app.UseRequestLocalization();

CurrentPrincipal

No ASP.NET Framework, CurrentPrincipal e Current seria definido como o usuário atual. Isso não está disponível no ASP.NET Core pronto para uso. O suporte para isso está disponível com esses adaptadores adicionando o ISetThreadCurrentPrincipal ao ponto de extremidade (disponível para controladores por meio do SetThreadCurrentPrincipalAttribute). No entanto, ele só deverá ser usado se o código não puder ser refatorado para remover o uso.

Recomendação: se possível, use a propriedade User ou User, em vez disso, passando-a para o site de chamada. Se não for possível, habilite a configuração do usuário atual e também considere definir a solicitação como um único thread lógico (consulte abaixo para obter detalhes).

O thread de solicitação não existe no ASP.NET Core

No ASP.NET Framework, uma solicitação tinha afinidade de thread e Current só estaria disponível se estivesse nesse thread. O ASP.NET Core não tem essa garantia, portantoCurrent, estará disponível no mesmo contexto assíncrono, mas não serão feitas garantias sobre threads.

Recomendação: se estiver lendo/gravando no HttpContext, você deve garantir que está fazendo isso de uma maneira de thread único. Você pode forçar uma solicitação a nunca ser executada simultaneamente em nenhum contexto assíncrono definindo o ISingleThreadedRequestMetadata. Isso terá implicações de desempenho e só deverá ser usado se você não puder refatorar o uso para garantir o acesso não simultâneo. Há uma implementação disponível para adicionar aos controladores com SingleThreadedRequestAttribute:

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

Request pode precisar ser pré-compilado

Por padrão, a solicitação de entrada nem sempre é buscada nem totalmente disponível. Para obter o comportamento visto em .NET Framework, você pode optar por pré-armazenar o fluxo de entrada. Isso lerá totalmente o fluxo de entrada e o armazenará em buffer na memória ou no disco (dependendo das configurações).

Recomendação: isso pode ser habilitado aplicando metadados de ponto de extremidade que implementam a interface IPreBufferRequestStreamMetadata. Isso está disponível como um atributo PreBufferRequestStreamAttribute que pode ser aplicado a controladores ou métodos.

Para habilitar isso em todos os pontos de extremidade MVC, há um método de extensão que pode ser usado da seguinte maneira:

app.MapDefaultControllerRoute()
    .PreBufferRequestStream();

Response pode exigir armazenamento em buffer

Algumas APIs em Response exigem que o fluxo de saída seja armazenado em buffer, como Output, End(), Clear()e SuppressContent.

Recomendação: para dar suporte ao comportamento para Response isso requer o armazenamento em buffer da resposta antes de enviar, os pontos de extremidade devem aceitar com metadados de ponto de extremidade implementando IBufferResponseStreamMetadata.

Para habilitar isso em todos os pontos de extremidade do MVC, há um método de extensão que pode ser usado da seguinte maneira:

app.MapDefaultControllerRoute()
    .BufferResponseStream();

Estado de sessão compartilhada

Para dar suporte a Session, os pontos de extremidade devem aceitar isso por meio de metadados que implementam ISessionMetadata.

Recomendação: para habilitar isso em todos os pontos de extremidade do MVC, há um método de extensão que pode ser usado da seguinte maneira:

app.MapDefaultControllerRoute()
    .RequireSystemWebAdapterSession();

Isso também requer alguma implementação de um repositório de sessão. Para obter detalhes das opções aqui, consulte aqui.

Sessão remota expõe ponto de extremidade adicional para o aplicativo

O suporte à sessão remota expõe um ponto de extremidade que permite que o aplicativo principal recupere informações de sessão. Isso pode fazer com que exista uma solicitação potencialmente de longa duração entre o aplicativo principal e o aplicativo de estrutura, mas atingirá o tempo limite com a solicitação atual ou a sessão atingirá o tempo limite (por padrão, 20 minutos).

Recomendação: verifique se a chave de API usada é forte e se a conexão com o aplicativo de estrutura é feita por SSL.

Os diretórios virtuais devem ser idênticos para aplicativos de estrutura e principais

A configuração do diretório virtual é usada para geração de rota, autorização e outros serviços dentro do sistema. Neste ponto, nenhum método confiável foi encontrado para habilitar diretórios virtuais diferentes devido ao funcionamento do ASP.NET Framework.

Recomendação: verifique se os dois aplicativos estão em sites diferentes (hosts e/ou portas) com o mesmo layout de diretório virtual/aplicativo.