Résolution des problèmes de SignalR

par Patrick Fletcher

Avertissement

Cette documentation ne concerne pas la dernière version de SignalR. Regardez ASP.NET Core SignalR.

Ce document décrit les problèmes courants de résolution des problèmes liés à SignalR.

Versions logicielles utilisées dans cette rubrique

Versions précédentes de cette rubrique

Pour plus d’informations sur les versions antérieures de SignalR, consultez Les versions antérieures de SignalR.

Questions et commentaires

Veuillez laisser des commentaires sur la façon dont vous avez aimé ce tutoriel et ce que nous pourrions améliorer dans les commentaires en bas de la page. Si vous avez des questions qui ne sont pas directement liées au didacticiel, vous pouvez les publier sur le forum ASP.NET SignalR ou StackOverflow.com.

Ce document contient les sections suivantes.

L’appel de méthodes entre le client et le serveur échoue silencieusement

Cette section décrit les causes possibles d’un appel de méthode entre le client et le serveur sans message d’erreur significatif. Dans une application SignalR, le serveur n’a aucune information sur les méthodes que le client implémente ; lorsque le serveur appelle une méthode cliente, le nom de la méthode et les données de paramètre sont envoyés au client et la méthode est exécutée uniquement s’il existe dans le format spécifié par le serveur. Si aucune méthode correspondante n’est trouvée sur le client, rien ne se produit et aucun message d’erreur n’est déclenché sur le serveur.

Pour examiner plus en détail les méthodes clientes qui ne sont pas appelées, vous pouvez activer la journalisation avant l’appel de la méthode de démarrage sur le hub pour voir quels appels proviennent du serveur. Pour activer la journalisation dans une application JavaScript, consultez Comment activer la journalisation côté client (version du client JavaScript). Pour activer la journalisation dans une application cliente .NET, consultez Comment activer la journalisation côté client (version du client .NET).

Méthode mal orthographiée, signature de méthode ou nom de hub incorrect

Si le nom ou la signature d’une méthode appelée ne correspond pas exactement à une méthode appropriée sur le client, l’appel échoue. Vérifiez que le nom de la méthode appelé par le serveur correspond au nom de la méthode sur le client. En outre, SignalR crée le proxy hub en utilisant des méthodes en camel case, comme c'est approprié en JavaScript, ainsi, une méthode appelée SendMessage sur le serveur serait appelée sendMessage dans le proxy client. Si vous utilisez l’attribut HubName dans votre code côté serveur, vérifiez que le nom utilisé correspond au nom utilisé pour créer le hub sur le client. Si vous n’utilisez pas l’attribut HubName, vérifiez que le nom du hub dans un client JavaScript est en camel case, tel que chatHub au lieu de ChatHub.

Nom de méthode dupliqué sur le client

Vérifiez que vous n’avez pas de méthode en double sur le client qui diffère uniquement par cas. Si votre application cliente a une méthode appelée sendMessage, vérifiez qu’il n’y a pas également de méthode appelée SendMessage .

Analyseur JSON manquant sur le client

SignalR nécessite qu’un analyseur JSON soit présent pour sérialiser les appels entre le serveur et le client. Si votre client n’a pas d’analyseur JSON intégré (par exemple, Internet Explorer 7), vous devez en inclure un dans votre application. Vous pouvez télécharger l’analyseur JSON ici.

Combinaison de la syntaxe Hub et PersistentConnection

SignalR utilise deux modèles de communication : Hubs et PersistentConnections. La syntaxe d’appel de ces deux modèles de communication est différente dans le code client. Si vous avez ajouté un hub dans votre code serveur, vérifiez que tout votre code client utilise la syntaxe de hub appropriée.

Code client JavaScript qui crée une PersistentConnection dans un client JavaScript

var myConnection = $.connection('/echo');

Code client JavaScript qui crée un proxy hub dans un client Javascript

var myHub = $.connection.MyHub;

Code serveur C# qui mappe un itinéraire à une connexion permanente

RouteTable.Routes.MapConnection<MyConnection>("my", "/echo");

Code de serveur C# qui mappe un itinéraire à un hub ou à plusieurs hubs si vous avez plusieurs applications

App.MapSignalR();

Connexion démarrée avant l’ajout d’abonnements

Si la connexion du hub est démarrée avant que les méthodes qui peuvent être appelées à partir du serveur soient ajoutées au proxy, les messages ne seront pas reçus. Le code JavaScript suivant ne démarre pas correctement le hub :

Code client JavaScript incorrect qui n’autorise pas la réception des messages Hubs

var chat = $.connection.chatHub;
$.connection.hub.start().done(function () {
    chat.client.broadcastMessage = function (name, message) {...};
});

Au lieu de cela, abonnez les méthodes avant d’appeler Start :

Code client JavaScript qui ajoute correctement des abonnements à un hub

var chat = $.connection.chatHub;
chat.client.broadcastMessage = function (name, message) {...};
    $.connection.hub.start().done(function () {
        ...
    });

Nom de méthode manquant sur le proxy hub

Vérifiez que la méthode définie sur le serveur est souscrite par le client. Même si le serveur définit la méthode, il doit toujours être ajouté au proxy client. Les méthodes peuvent être ajoutées au proxy client de la manière suivante (notez que la méthode est ajoutée au client membre du hub, et non au hub directement) :

Code client JavaScript qui ajoute des méthodes à un proxy hub

// Method added to proxy in JavaScript:
myHubProxy.server.method1 = function (param1, param2) {...};
//Multiple methods added to proxy in JavaScript using jQuery:
$.extend(myHubProxy.server, {
    method1: function (param1, param2) {...},
    method2: function (param3, param4) {...}
});

Méthodes de hub ou de concentrateur non déclarées comme publiques

Pour être visible sur le client, l’implémentation et les méthodes du hub doivent être déclarées en tant que public.

Accès au hub à partir d’une autre application

SignalR Hubs est accessible uniquement par le biais d’applications qui implémentent des clients SignalR. SignalR ne peut pas interagir avec d’autres bibliothèques de communication (comme soap ou services web WCF).) S’il n’existe aucun client SignalR disponible pour votre plateforme cible, vous ne pouvez pas accéder directement au point de terminaison du serveur.

Sérialisation manuelle des données

SignalR utilise automatiquement JSON pour sérialiser vos paramètres de méthode. Il n’est pas nécessaire de le faire vous-même.

Méthode Remote Hub non exécutée sur le client dans la fonction OnDisconnected

Ce comportement est voulu. Lorsqu’il OnDisconnected est appelé, le hub est déjà entré dans l’état Disconnected , ce qui n’autorise pas l’appel de méthodes de hub supplémentaires.

Code serveur C# qui exécute correctement du code dans l’événement OnDisconnected

public class MyHub : Hub
{
    public override Task OnDisconnected()
    {
        // Do what you want here
        return base.OnDisconnected();
    }
}

OnDisconnect ne se déclenche pas à des moments cohérents

Ce comportement est voulu. Lorsqu’un utilisateur tente de s’éloigner d’une page avec une connexion SignalR active, le client SignalR effectue ensuite une tentative optimale pour avertir le serveur que la connexion cliente sera arrêtée. Si la meilleure tentative d’effort du client SignalR ne parvient pas à atteindre le serveur, le serveur supprime la connexion après une configuration ultérieure DisconnectTimeout , auquel cas l’événement OnDisconnected se déclenche. Si la meilleure tentative d’effort du client SignalR réussit, l’événement OnDisconnected se déclenche immédiatement.

Pour plus d’informations sur la définition du DisconnectTimeout paramètre, consultez Gestion des événements de durée de vie des connexions : DisconnectTimeout.

Limite de connexion atteinte

Lorsque vous utilisez la version complète d’IIS sur un système d’exploitation client comme Windows 7, une limite de 10 connexions est imposée. Lorsque vous utilisez un système d’exploitation client, utilisez IIS Express à la place pour éviter cette limite.

Connexion inter-domaines non configurée correctement

Si une connexion inter-domaines (connexion pour laquelle l’URL SignalR n’est pas dans le même domaine que la page d’hébergement) n’est pas configurée correctement, la connexion peut échouer sans message d’erreur. Pour plus d’informations sur l’activation de la communication inter-domaines, consultez Comment établir une connexion inter-domaines.

Connexion utilisant NTLM (Active Directory) qui ne fonctionne pas dans le client .NET

Une connexion dans une application cliente .NET qui utilise la sécurité du domaine peut échouer si la connexion n’est pas configurée correctement. Pour utiliser SignalR dans un environnement de domaine, définissez la propriété de connexion requise comme suit :

Code client C# qui implémente les informations d’identification de connexion

connection.Credentials = CredentialCache.DefaultCredentials;

Configurer les websockets de IIS pour utiliser ping/pong afin de détecter un client inactif

Les serveurs SignalR ne savent pas si le client est mort ou non et s’appuient sur la notification du websocket sous-jacent pour les échecs de connexion, c’est-à-dire le OnClose rappel. Une solution à ce problème consiste à configurer des websockets IIS pour effectuer le ping/pong pour vous. Cela garantit que votre connexion se ferme si elle s’interrompt de façon inattendue. Pour plus d’informations, consultez ce billet stackoverflow.

Autres problèmes de connexion

Cette section décrit les causes et solutions des symptômes spécifiques ou des messages d’erreur qui se produisent pendant une connexion.

Erreur « Démarrer doit être appelé avant que les données puissent être envoyées »

Cette erreur est généralement observée si le code fait référence à des objets SignalR avant le démarrage de la connexion. La configuration pour les gestionnaires et autres qui appeleront des méthodes définies sur le serveur doit être établie une fois la connexion terminée. Notez que l’appel à Start est asynchrone, de sorte que le code après l’appel peut être exécuté avant qu’il ne se termine. La meilleure façon d’ajouter des gestionnaires après le démarrage complet d’une connexion consiste à les placer dans une fonction de rappel passée en tant que paramètre à la méthode de démarrage :

Code client JavaScript qui ajoute correctement des gestionnaires d’événements qui référencent des objets SignalR

$.connection.hub.start().done(function () {
    // Wire up Send button to call NewContosoChatMessage on the server.
    $('#newContosoChatMessage').click(function () {
        contosoChatHubProxy.server.newContosoChatMessage(
            $('#displayname').val(), $('#message').val());
            $('#message').val('').focus();
    });

Cette erreur s’affiche également si une connexion s’arrête pendant que les objets SignalR sont toujours référencés.

Erreur « 301 Déplacé définitivement » ou « 302 Déplacé temporairement »

Cette erreur peut être observée si le projet contient un dossier appelé SignalR, qui interfère avec le proxy créé automatiquement. Pour éviter cette erreur, n’utilisez pas de dossier appelé SignalR dans votre application ou désactivez la génération automatique du proxy. Pour plus d’informations, consultez le proxy généré et ce qu’il fait pour vous .

Erreur « 403 Interdit » dans le client .NET ou Silverlight

Cette erreur peut se produire dans les environnements inter-domaines où la communication inter-domaines n’est pas correctement activée. Pour plus d’informations sur l’activation de la communication inter-domaines, consultez Comment établir une connexion inter-domaines. Pour établir une connexion inter-domaines dans un client Silverlight, consultez connexions inter-domaines à partir de clients Silverlight.

Erreur « 404 Introuvable »

Il existe plusieurs causes pour ce problème. Vérifiez tous les éléments suivants :

  • Référence d’adresse proxy hub non correctement mise en forme : Cette erreur est généralement observée si la référence à l’adresse proxy du hub généré n’est pas correctement mise en forme. Vérifiez que la référence à l’adresse du hub est correctement établie. Découvrez comment référencer le proxy généré dynamiquement pour plus d’informations.

  • Ajout d’itinéraires à l’application avant d’ajouter l’itinéraire hub : Si votre application utilise d’autres itinéraires, vérifiez que le premier itinéraire ajouté est l’appel à MapSignalR.

  • Utilisation d’IIS 7 ou 7.5 sans mise à jour pour les URL sans extension : L’utilisation d’IIS 7 ou 7.5 nécessite une mise à jour pour les URL sans extension afin que le serveur puisse fournir l’accès aux définitions du hub à l’adresse /signalr/hubs. La mise à jour est disponible ici.

  • Cache IIS obsolète ou endommagé : Pour vérifier que le contenu du cache n’est pas obsolète, entrez la commande suivante dans une fenêtre PowerShell pour effacer le cache :

    net stop w3svc
Remove-Item -Path "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\*" -Force -Recurse
net start w3svc

« Erreur du serveur interne 500 »

Il s’agit d’une erreur très générique qui pourrait avoir une grande variété de causes. Les détails de l’erreur doivent apparaître dans le journal des événements du serveur ou se trouvent via le débogage du serveur. Des informations d’erreur plus détaillées peuvent être obtenues en activant l'affichage des erreurs détaillées sur le serveur. Pour plus d’informations, consultez Comment gérer les erreurs dans la classe Hub.

Cette erreur est également généralement observée si un pare-feu ou un proxy n’est pas configuré correctement, ce qui entraîne la réécriture des en-têtes de requête. La solution consiste à vérifier que le port 80 est activé sur le pare-feu ou le proxy.

« Code de réponse inattendu : 500 »

Cette erreur peut se produire si la version du .NET Framework utilisée dans l’application ne correspond pas à la version spécifiée dans Web.Config. La solution consiste à vérifier que .NET 4.5 est utilisé dans les paramètres de l’application et dans le fichier Web.Config.

Erreur « TypeError : <hubType> n’est pas défini »

Cette erreur se produira si l’appel à MapSignalR n’est pas effectué correctement. Pour plus d’informations, consultez Comment inscrire SignalR Middleware et configurer des options SignalR .

JsonSerializationException n’a pas été géré par le code utilisateur

Vérifiez que les paramètres que vous envoyez à vos méthodes n’incluent pas de types non sérialisables (comme les handles de fichiers ou les connexions de base de données). Si vous devez utiliser des membres sur un objet côté serveur que vous ne souhaitez pas envoyer au client (pour des raisons de sécurité ou pour des raisons de sérialisation), utilisez l’attribut JSONIgnore .

Erreur « Erreur de protocole : Transport inconnu »

Cette erreur peut se produire si le client ne prend pas en charge les transports que SignalR utilise. Consultez Transports et solutions de repli pour obtenir des informations sur les navigateurs pouvant être utilisés avec SignalR.

« La génération du proxy JavaScript Hub a été désactivée . »

Cette erreur se produit si DisableJavaScriptProxies est définie tout en incluant une référence au proxy généré dynamiquement à l’adresse signalr/hubs. Pour plus d’informations sur la création manuelle du proxy, consultez le proxy généré et ce qu’il fait pour vous.

« L’ID de connexion est au format incorrect » ou « L’identité de l’utilisateur ne peut pas changer pendant une connexion SignalR active »

Cette erreur peut être observée si l’authentification est utilisée et que le client est déconnecté avant l’arrêt de la connexion. La solution consiste à arrêter la connexion SignalR avant de déconnecter le client.

« Erreur non détectée : SignalR : jQuery introuvable. Vérifiez que jQuery est référencé avant l’erreur SignalR.js fichier »

Le client JavaScript SignalR nécessite l’exécution de jQuery. Vérifiez que votre référence à jQuery est correcte, que le chemin utilisé est valide et que la référence à jQuery est antérieure à la référence à SignalR.

Erreur « Uncaught TypeError : Impossible de lire la propriété '<property>' d'une valeur non définie »

Cette erreur provient de ne pas avoir jQuery ou le proxy hubs référencé correctement. Vérifiez que votre référence à jQuery et au proxy hubs est correcte, que le chemin utilisé est valide et que la référence à jQuery est avant la référence au proxy hubs. La référence par défaut au proxy hubs doit ressembler à ce qui suit :

Code côté client HTML qui référence correctement le proxy Hubs

<script src="/signalr/hubs"></script>

Erreur « RuntimeBinderException n’a pas été gérée par le code utilisateur »

Cette erreur peut se produire lorsque l'usage incorrect de Hub.On est effectué. Si la méthode a une valeur de retour, le type de retour doit être spécifié en tant que paramètre de type générique :

Méthode définie sur le client (sans proxy généré)

MyHub.On<ReturnType>("MethodName", LocalMethod);

L’ID de connexion est incohérent ou la connexion se coupe entre les chargements des pages

Ce comportement est voulu. Étant donné que l’objet hub est hébergé dans l’objet de page, le hub est détruit lors de l’actualisation de la page. Une application multipage doit maintenir l’association entre les utilisateurs et les ID de connexion afin qu’elles soient cohérentes entre les chargements de page. Les ID de connexion peuvent être stockés sur le serveur dans un ConcurrentDictionary objet ou une base de données.

Erreur « La valeur ne peut pas être null »

Les méthodes côté serveur avec des paramètres facultatifs ne sont actuellement pas prises en charge ; si le paramètre facultatif est omis, la méthode échoue. Pour plus d’informations, consultez Paramètres facultatifs.

Erreur « Firefox ne peut pas établir une connexion au serveur à <l’adresse> » dans Firebug

Ce message d’erreur peut être affiché dans Firebug si la négociation du transport WebSocket échoue et qu’un autre transport est utilisé à la place. Ce comportement est voulu.

Erreur « Le certificat distant n’est pas valide en fonction de la procédure de validation » dans l’application cliente .NET

Si votre serveur requiert des certificats clients personnalisés, vous pouvez ajouter un certificat x509certificate à la connexion avant que la demande ne soit effectuée. Ajoutez le certificat à la connexion à l’aide de Connection.AddClientCertificate.

La connexion est abandonnée après expiration de l’authentification

Ce comportement est voulu. Les informations d’identification d’authentification ne peuvent pas être modifiées lorsqu’une connexion est active ; pour actualiser les informations d’identification, la connexion doit être arrêtée et redémarrée.

OnConnected est appelé deux fois lors de l’utilisation de jQuery Mobile

La fonction de initializePage jQuery Mobile force les scripts de chaque page à réexécuter, créant ainsi une deuxième connexion. Les solutions à ce problème sont les suivantes :

  • Incluez la référence à jQuery Mobile avant votre fichier JavaScript.
  • Désactivez la initializePage fonction en définissant $.mobile.autoInitializePage = false.
  • Attendez que la page termine l’initialisation avant de démarrer la connexion.

Les messages sont retardés dans les applications Silverlight à l’aide des événements envoyés par le serveur

Les messages sont retardés lors de l’utilisation des événements envoyés par le serveur sur Silverlight. Pour imposer l'utilisation de l'interrogation longue à la place, utilisez la commande suivante au démarrage de la connexion :

connection.Start(new LongPollingTransport());

« Autorisation refusée » à l’aide du protocole Forever Frame

Il s’agit d’un problème connu, décrit ici. Ce symptôme peut être vu à l’aide de la dernière bibliothèque JQuery ; la solution de contournement consiste à rétrograder votre application vers JQuery 1.8.2.

« InvalidOperationException : Requête de socket web non valide.

Cette erreur peut se produire si le protocole WebSocket est utilisé, mais que le proxy réseau modifie les en-têtes de requête. La solution consiste à configurer le proxy pour autoriser WebSocket sur le port 80.

« Exception : <nom de la méthode> n’a pas pu être résolu » lorsque le client appelle la méthode sur le serveur

Cette erreur peut provenir de l’utilisation de types de données qui ne peuvent pas être découverts dans une charge utile JSON, telle que Array. La solution de contournement consiste à utiliser un type de données détectable par JSON, tel que IList. Pour plus d’informations, consultez .NET Client n’arrive pas à appeler des méthodes du hub avec des paramètres sous forme de tableau.

Erreurs de compilation et côté serveur

La section suivante contient des solutions possibles aux erreurs de compilateur et de runtime côté serveur.

La référence à l’instance hub est Null

Étant donné qu’une instance hub est créée pour chaque connexion, vous ne pouvez pas créer une instance d’un hub dans votre code vous-même. Pour appeler des méthodes sur un hub en dehors du hub lui-même, consultez Comment appeler des méthodes clientes et gérer des groupes à partir de l’extérieur de la classe Hub pour obtenir une référence au contexte du hub.

HTTPContext.Current.Session a la valeur Null

Ce comportement est voulu. SignalR ne prend pas en charge l’état de session ASP.NET, car l’activation de l’état de session interrompt la messagerie duplex.

Aucune méthode appropriée à remplacer

Vous pouvez voir cette erreur si vous utilisez du code à partir d’une documentation ou d’un blog plus ancien. Vérifiez que vous ne référencez pas les noms des méthodes qui ont été modifiées ou déconseillées (par exemple OnConnectedAsync).

HostContextExtensions.WebSocketServerUrl a la valeur Null

Ce comportement est voulu. Ce membre est déconseillé et ne doit pas être utilisé.

« Une route nommée « signalr.hubs » se trouve déjà dans la collection d’itinéraires »

Cette erreur se produira si MapSignalR est appelée deux fois par votre application. Certains exemples d’applications appellent MapSignalR directement dans la classe Startup ; d’autres effectuent l’appel dans une classe wrapper. Vérifiez que votre application ne fait pas les deux.

WebSocket n’est pas utilisé

Si vous avez vérifié que votre serveur et vos clients répondent aux exigences de WebSocket (répertoriés dans le document Plateformes prises en charge ), vous devez activer WebSocket sur votre serveur. Vous trouverez des instructions pour effectuer cette opération ici.

$.connection n’est pas défini

Cette erreur indique que les scripts d’une page ne sont pas chargés correctement, ou que le proxy hub n’est pas accessible ou est accessible de manière incorrecte. Vérifiez que les références de script sur votre page correspondent aux scripts chargés dans votre projet, et que /signalr/hubs est accessible dans un navigateur lorsque le serveur est en cours d’exécution.

Impossible de trouver un ou plusieurs types requis pour compiler une expression dynamique

Cette erreur indique que la Microsoft.CSharp bibliothèque est manquante. Ajoutez-le dans l’onglet Assemblys-Framework>.

L’état de l’appelant n’est pas accessible à partir de Clients.Caller en Visual Basic ou dans un hub fortement typé ; erreur « Conversion du type 'Task(Of Object)' en type 'String' n’est pas valide »

Pour accéder à l’état de l’appelant dans Visual Basic ou dans un hub fortement typé, utilisez la Clients.CallerState propriété (introduite dans SignalR 2.1) au lieu de Clients.Caller.

Problèmes liés à Visual Studio

Cette section décrit les problèmes rencontrés dans Visual Studio.

Le nœud Documents de script n’apparaît pas dans l’Explorateur de solutions

Certains de nos didacticiels vous dirigent vers le nœud « Documents de script » dans l’Explorateur de solutions lors du débogage. Ce nœud est produit par le débogueur JavaScript et s’affiche uniquement lors du débogage des clients de navigateur dans Internet Explorer ; le nœud n’apparaît pas si Chrome ou Firefox sont utilisés. Le débogueur JavaScript ne s’exécute pas non plus si un autre débogueur client est en cours d’exécution, tel que le débogueur Silverlight.

SignalR ne fonctionne pas sur Visual Studio 2008 ou version antérieure

Ce comportement est voulu. SignalR nécessite .NET Framework 4 ou version ultérieure ; Cela nécessite que les applications SignalR soient développées dans Visual Studio 2010 ou version ultérieure. Le composant serveur de SignalR nécessite .NET Framework 4.5.

Problèmes IIS

Cette section contient des problèmes liés à Internet Information Services.

SignalR fonctionne sur le serveur de développement Visual Studio, mais pas dans IIS

SignalR est pris en charge sur IIS 7.0 et 7.5, mais la prise en charge des URL sans extension doit être ajoutée. Pour ajouter la prise en charge des URL sans extension, consultez https://support.microsoft.com/kb/980368

SignalR nécessite ASP.NET être installé sur le serveur (ASP.NET n’est pas installé sur IIS par défaut). Pour installer ASP.NET, consultez ASP.NET Téléchargements.

Problèmes liés à Microsoft Azure

Cette section contient des problèmes avec Microsoft Azure.

FileLoadException lors de l’hébergement de SignalR dans un rôle De travail Azure

L’hébergement de SignalR dans un rôle De travail Azure peut entraîner l’exception « Impossible de charger le fichier ou l’assembly « Microsoft.Owin, Version=2.0.0.0 ». Il s’agit d’un problème connu avec NuGet ; les redirections de liaison ne sont pas ajoutées automatiquement dans les projets de rôle de travail Azure. Pour résoudre ce problème, vous pouvez ajouter manuellement les redirections de liaison. Ajoutez les lignes suivantes au app.config fichier de votre projet de rôle de travail.

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-2.0.2.0" newVersion="2.0.2.0" />
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-2.0.2.0" newVersion="2.0.2.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

Les messages ne sont pas reçus via le backplane Azure après avoir modifié les noms de rubriques

Les rubriques utilisées par le backplane Azure sont gérées en interne ; elles ne sont pas destinées à être configurables par l’utilisateur.

  • Last updated on