Les méthodes SignalR Hub essaient de résoudre les paramètres à partir de l’ID

  • Article

Les méthodes SignalR Hub prennent désormais en charge l’injection de services à partir de votre conteneur d’injection de dépendances. Dans de rares cas, cela peut arrêter les applications qui ont un type dans l’injection de dépendances également accepté dans les méthodes Hub des messages de client SignalR.

Version introduite

ASP.NET Core 7.0

Comportement précédent

Si vous aviez accepté un type dans votre méthode Hub qui se trouvait également dans votre conteneur d’injection de dépendances, le type était toujours résolu par un message envoyé par le client.

Services.AddScoped<SomeCustomType>();

class MyHub : Hub
{
    // type always comes from the client, never comes from DI
    public Task Method(string text, SomeCustomType type) => Task.CompletedTask;
}

Nouveau comportement

Les types dans l’injection de dépendances sont vérifiés au démarrage de l’application en utilisant IServiceProviderIsService pour déterminer si un argument dans une méthode Hub provient de l’injection de dépendances ou du client.

Dans l’exemple suivant, qui suppose que vous utilisez le conteneur d’injection de dépendances par défaut, SomeCustomType provient du conteneur d’injection de dépendances et non du client. Si le client tente d’envoyer SomeCustomType, une erreur s’affiche :

Services.AddScoped<SomeCustomType>();

class MyHub : Hub
{
    // comes from DI by default
    public Task Method(string text, SomeCustomType type) => Task.CompletedTask;
}

Type de changement cassant

Ce changement affecte la compatibilité de la source.

Raison du changement

Ce changement améliore l’expérience utilisateur en cas d’utilisation de différents services dans différentes méthodes Hub. Il améliore également les performances, car il ne demande pas à l’utilisateur d’injecter toutes les dépendances dans le constructeur du Hub.

La probabilité d’arrêt des applications est faible, car il n’est pas courant d’avoir un type dans l’injection de dépendances qui soit en même temps un argument dans votre méthode Hub.

Si votre application est arrêtée par ce changement, vous pouvez désactiver la fonctionnalité en définissant DisableImplicitFromServicesParameters sur true :

Services.AddSignalR(options =>
{
    options.DisableImplicitFromServicesParameters = true;
});

Si votre application est arrêtée par ce changement, mais que vous voulez utiliser la fonctionnalité sans arrêter les clients, vous pouvez la désactiver comme indiqué ci-dessus et utiliser un attribut qui implémente IFromServiceMetadata sur les nouveaux arguments/méthodes Hub :

Services.AddScoped<SomeCustomType>();
Services.AddScoped<SomeCustomType2>();

class MyHub : Hub
{
    // old method with new feature (non-breaking), only SomeCustomType2 is resolved from DI
    public Task MethodA(string arguments, SomeCustomType type, [FromServices] SomeCustomType2 type2);

    // new method
    public Task MethodB(string arguments, [FromServices] SomeCustomType type);
}

API affectées

Méthodes Hub