Partager via

Aide sur l’utilisation

  • Article

Microsoft.AspNetCore.SystemWebAdapters fournit une couche d’émulation pour imiter le comportement d’ASP.NET Framework sur ASP.NET Core. Vous trouverez ci-dessous quelques conseils pour certains des éléments à prendre en compte lors de leur utilisation :

Durée de vie HttpContext

Les adaptateurs sont soutenus par HttpContext que vous ne pouvez pas utiliser au-delà de la durée de vie d’une requête. Ainsi, vous ne pouvez pas utiliser HttpContext exécuté sur ASP.NET Core au-delà d’une requête également, alors que sur ASP.NET Framework, ce système fonctionne parfois. Une exception ObjectDisposedException est émise en cas d’utilisation au-delà d’une fin de requête.

Recommandation : stockez les valeurs nécessaires dans un OCT, puis tenez-vous-en à cela.

Conversion en HttpContext

Il existe deux façons de convertir un HttpContext en HttpContext :

  • Transtypage implicite
  • Utilisation du constructeur

Recommandation : dans la plupart des cas, nous vous recommandons la conversion implicite, car elle met en cache l’instance créée et garantit un seul HttpContext par requête.

CurrentCulture n’est pas défini par défaut

Dans ASP.NET Framework, CurrentCulture a été défini pour une requête, mais cette opération n’est pas effectuée automatiquement dans ASP.NET Core. Au lieu de cela, vous devez ajouter l’intergiciel approprié à votre pipeline.

Recommandation : veuillez consulter localisation ASP.NET Core si vous souhaitez en savoir plus sur la façon d’activer cette fonctionnalité.

Le moyen le plus simple de l’activer avec un comportement similaire à ASP.NET Framework consiste à ajouter les éléments suivants à votre pipeline :

app.UseRequestLocalization();

CurrentPrincipal

Dans ASP.NET Framework, CurrentPrincipal et Current étaient définis sur l’utilisateur actuel. Cette fonction n’est pas disponible sur ASP.NET Core prêt à l’emploi. Cette prise en charge est disponible avec ces adaptateurs par ajout de l’élément ISetThreadCurrentPrincipal au point de terminaison (disponible pour les contrôleurs via l’attribut SetThreadCurrentPrincipalAttribute). Toutefois, vous ne devez l’utiliser que si le code ne peut pas être refactorisé pour supprimer l’utilisation.

Recommandation : si possible, utilisez la propriété User ou User à la place en la transmettant au site d’appel. Si ce n’est pas possible, activez la définition de l’utilisateur actuel. Nous vous recommandons également de définir la requête comme un thread unique logique (veuillez consulter le texte ci-dessous si vous souhaitez en savoir plus).

Le thread de requête n’existe pas dans ASP.NET Core

Dans ASP.NET Framework, une requête avait une affinité de thread et Current n’était disponible que sur ce thread. ASP.NET Core ne dispose pas de cette garantie, si bien que Current est disponible dans le même contexte asynchrone, mais aucune garantie concernant les threads n’est offerte.

Recommandation : si vous lisez/écrivez dans HttpContext, vous veiller à utiliser un seul thread. Vous pouvez forcer une requête à ne jamais s’exécuter simultanément sur un contexte asynchrone en définissant ISingleThreadedRequestMetadata. Cette méthode aura des implications sur le niveau de performance et ne doit être utilisée que si vous ne pouvez pas refactoriser l’utilisation pour garantir un accès non simultané. Une implémentation peut être ajoutée aux contrôleurs avec SingleThreadedRequestAttribute :

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

La requête Request devra sans doute être placée en mémoire tampon pour utilisation ultérieure

Par défaut, la requête entrante ne peut pas toujours faire l’objet d’une recherche est n’est pas toujours entièrement disponible. Pour obtenir un comportement visible dans .NET Framework, vous pouvez choisir de placer le flux d’entrée en mémoire tampon pour utilisation ultérieur. Cette méthode permet de lire entièrement le flux entrant, puis de le placer en mémoire tampon ou sur le disque (selon les paramètres).

Recommandation : vous pouvez l’activer en appliquant des métadonnées de point de terminaison qui implémentent l’interface IPreBufferRequestStreamMetadata. Cet élément est disponible en tant qu’attribut PreBufferRequestStreamAttribute applicable aux contrôleurs ou aux méthodes.

Pour activer cet élément sur tous les points de terminaison MVC, il existe une méthode d’extension utilisable comme suit :

app.MapDefaultControllerRoute()
    .PreBufferRequestStream();

Response peut nécessiter une mise en mémoire tampon.

Certaines API sur Response nécessitent que le flux de sortie soit mis en mémoire tampon, par exemple Output, End(), Clear()et SuppressContent.

Recommandation : pour prendre en charge le comportement de Response qui nécessite la mise en mémoire tampon de la réponse avant l’envoi, les points de terminaison doivent choisir cette option avec des métadonnées de point de terminaison implémentant IBufferResponseStreamMetadata.

Pour activer cet élément sur tous les points de terminaison MVC, il existe une méthode d’extension utilisable comme suit :

app.MapDefaultControllerRoute()
    .BufferResponseStream();

État de la session partagée

Pour prendre en charge Session, les points de terminaison doivent choisir cette option via des métadonnées implémentant ISessionMetadata.

Recommandation : pour activer cet élément sur tous les points de terminaison MVC, il existe une méthode d’extension utilisable comme suit :

app.MapDefaultControllerRoute()
    .RequireSystemWebAdapterSession();

Cela nécessite également une implémentation d’un magasin de sessions. Si vous souhaitez en savoir plus sur les options disponibles ici, veuillez cliquer ici.

La session à distance expose un point de terminaison supplémentaire pour l’application

La prise en charge des sessions à distance expose un point de terminaison qui permet à l’application Core de récupérer des informations de session. Cela générer une requête potentiellement longue entre l’application Core et l’application Framework, mais le délai d’attente expirera avec la requête actuelle ou le délai d’expiration de session (la valeur par défaut est de 20 minutes).

Recommandation : vérifiez que la clé API utilisée est solide et que la connexion avec l’application Framework est établie via SSL.

Les répertoires virtuels doivent être identiques pour les applications Framework et Core.

La configuration du répertoire virtuel sert à la génération d’itinéraires, l’autorisation et d’autres services au sein du système. À ce stade, nous n’avons trouvé aucune méthode fiable pour activer différents répertoires virtuels en raison du fonctionnement d’ASP.NET Framework.

Recommandation : vérifiez que vos deux applications se trouvent sur des sites différents (hôtes et/ou ports) avec la même disposition d’application/de répertoire virtuel.