Руководство по использованию

Microsoft.AspNetCore.SystemWebAdapters предоставляет слой эмуляции для имитации поведения из платформы ASP.NET в ASP.NET Core. Ниже приведены некоторые рекомендации по некоторым соображениям при их использовании:

HttpContext продолжительность жизни

Адаптеры поддерживаются HttpContext , которые не могут использоваться в прошлом времени существования запроса. Таким образом, HttpContext при запуске в ASP.NET Core нельзя использовать запрос, а в ASP платформа .NET Framework время от времени он будет работать. Вызывается ObjectDisposedException в случаях, когда он используется после окончания запроса.

Рекомендация. Сохраните необходимые значения в POCO и удерживайте на этом.

Преобразование в HttpContext

Существует два способа преобразования в HttpContext :HttpContext

• Неявное приведение
• Использование конструктора

Рекомендация. В большинстве случаев неявное приведение должно быть предпочтительно, так как это кэширует созданный экземпляр и гарантирует только один запрос HttpContext .

CurrentCulture значение по умолчанию не задано

В ASP платформа .NET Framework CurrentCulture был установлен запрос, но это не выполняется автоматически в ASP.NET Core. Вместо этого необходимо добавить соответствующее ПО промежуточного слоя в конвейер.

Рекомендация. Дополнительные сведения о том, как включить эту функцию, см. в разделе ASP.NET Базовая локализация .

Самый простой способ включить это с аналогичным поведением, как ASP платформа .NET Framework будет добавить следующее в конвейер:

app.UseRequestLocalization();

CurrentPrincipal

В ASP платформа .NET Framework CurrentPrincipal и Current будет задан текущий пользователь. Это недоступно в ASP.NET Core из коробки. Поддержка этого доступна с помощью этих адаптеров путем добавления ISetThreadCurrentPrincipal в конечную точку (доступной для контроллеров через ).SetThreadCurrentPrincipalAttribute Однако его следует использовать только в том случае, если код не может быть рефакторингован для удаления использования.

Рекомендация. Если это возможно, используйте свойство User или User вместо этого передайте его на вызывающий сайт. Если это невозможно, включите настройку текущего пользователя, а также рассмотрите возможность настройки запроса в виде логического единого потока (см. ниже сведения).

Поток запросов не существует в ASP.NET Core

В ASP платформа .NET Framework запрос имел сходство потоков и Current будет доступен только в том случае, если в этом потоке. ASP.NET Core не имеет этой гарантии, поэтому Current она будет доступна в том же асинхронном контексте, но никаких гарантий о потоках не производится.

Рекомендация. При чтении и записи в него HttpContextнеобходимо убедиться, что вы делаете это одним потоком. Вы можете принудительно заставить запрос никогда не выполняться одновременно в любом асинхронном контексте, задав параметр ISingleThreadedRequestMetadata. Это будет иметь последствия для производительности и должно использоваться только в том случае, если вы не можете рефакторинг использования, чтобы обеспечить не одновременный доступ. Существует реализация, доступная для добавления в контроллеры с помощью SingleThreadedRequestAttribute:

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

Request Может потребоваться предварительное руководство.

По умолчанию входящие запросы не всегда доступны и не полностью доступны. Чтобы получить поведение, видное в платформа .NET Framework, вы можете выбрать предварительную настройку входного потока. Это полностью считывает входящий поток и буферизирует его в память или диск (в зависимости от параметров).

Рекомендация. Это можно включить, применяя метаданные конечной IPreBufferRequestStreamMetadata точки, реализующие интерфейс. Это доступно как атрибут PreBufferRequestStreamAttribute , который можно применить к контроллерам или методам.

Чтобы включить это для всех конечных точек MVC, существует метод расширения, который можно использовать следующим образом:

app.MapDefaultControllerRoute()
    .PreBufferRequestStream();

Response Может потребоваться буферизация

Для некоторых API Response требуется буферизация выходного потока, например Output, End(), Clear()и SuppressContent.

Рекомендация. Для поддержки поведения для Response этого требуется буферизация ответа перед отправкой, конечные точки должны выбрать его с помощью метаданных конечной точки, реализующих IBufferResponseStreamMetadata.

Чтобы включить это для всех конечных точек MVC, существует метод расширения, который можно использовать следующим образом:

app.MapDefaultControllerRoute()
    .BufferResponseStream();

Состояние общего сеанса

Для поддержки Sessionконечные точки должны принять его через реализацию ISessionMetadataметаданных.

Рекомендация. Чтобы включить это для всех конечных точек MVC, существует метод расширения, который можно использовать следующим образом:

app.MapDefaultControllerRoute()
    .RequireSystemWebAdapterSession();

Для этого также требуется некоторая реализация хранилища сеансов. Дополнительные сведения о параметрах см . здесь.

Удаленный сеанс предоставляет дополнительную конечную точку для приложения

Поддержка удаленного сеанса предоставляет конечную точку, которая позволяет базовому приложению получать сведения о сеансе. Это может привести к возникновению потенциально длительного запроса между основным приложением и приложением платформы, но время ожидания текущего запроса или времени ожидания сеанса (по умолчанию — 20 минут).

Рекомендация. Убедитесь, что используемый ключ API является сильным и что подключение к приложению платформы выполняется по протоколу SSL.

Виртуальные каталоги должны быть идентичными для платформы и основных приложений

Настройка виртуального каталога используется для создания маршрутов, авторизации и других служб в системе. На этом этапе надежный метод не найден для включения различных виртуальных каталогов из-за работы ASP платформа .NET Framework.

Рекомендация. Убедитесь, что два приложения находятся на разных сайтах (узлах и/или портах) с одинаковым макетом приложения или виртуального каталога.