Résolution des problèmes de SignalR

Article
06/16/2023

Avertissement

Cette documentation ne concerne pas la dernière version de SignalR. Jetez un coup d’œil à ASP.NET Core SignalR.

Ce document décrit les problèmes courants liés à SignalR.

Versions logicielles utilisées dans cette rubrique

Visual Studio 2013

.NET 4.5

SignalR version 2

Versions précédentes de cette rubrique

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

Questions et commentaires

Laissez 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 tutoriel, 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 en mode silencieux
Configuration de websockets IIS pour effectuer un ping/pong pour détecter un client mort
Autres problèmes de connexion
Erreurs de compilation et côté serveur
Problèmes liés à Visual Studio
Problèmes liés aux services Internet Information Services
Problèmes liés à Microsoft Azure

L’appel de méthodes entre le client et le serveur échoue en mode silencieux

Cette section décrit les causes possibles de l’échec d’un appel de méthode entre le client et le serveur sans message d’erreur significatif. Dans une application SignalR, le serveur ne dispose d’aucune information sur les méthodes que le client implémente ; lorsque le serveur appelle une méthode cliente, les données de nom et de paramètre de la méthode sont envoyées au client, et la méthode est exécutée uniquement si elle 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 start 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 Guide pratique pour activer la journalisation côté client (version du client .NET).

Méthode mal orthographié, signature de méthode incorrecte 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ée par le serveur correspond au nom de la méthode sur le client. En outre, SignalR crée le proxy hub à l’aide de méthodes à casses mixtes, comme il convient dans JavaScript, afin qu’une méthode appelée SendMessage sur le serveur soit 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 à casse mixte, par exemple chatHub au lieu de ChatHub.

Nom de la méthode en double sur le client

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

Analyseur JSON manquant sur le client

SignalR nécessite la présence d’un analyseur JSON 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 un 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 de 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 sont 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 de messages Hubs

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

Ajoutez plutôt les abonnements de méthode 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 abonnée à sur le client. Même si le serveur définit la méthode, elle doit toujours être ajoutée au proxy client. Les méthodes peuvent être ajoutées au proxy client des manières suivantes (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 hub ou hub 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 les services web SOAP ou 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 hub distant non exécutée sur le client dans la fonction OnDisconnected

Ce comportement est normal. Quand OnDisconnected est appelé, le hub est déjà entré dans l’état Disconnected , ce qui ne permet pas d’appeler d’autres méthodes de hub.

Code du serveur C# qui exécute correctement le 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 normal. Lorsqu’un utilisateur tente de s’éloigner d’une page avec une connexion SignalR active, le client SignalR tente alors de prévenir le serveur que la connexion cliente sera arrêtée. Si la tentative du client SignalR ne parvient pas à atteindre le serveur, le serveur supprimera la connexion après une configuration ultérieure DisconnectTimeout , auquel cas l’événement OnDisconnected se déclenchera. Si la 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 de connexion : DisconnectTimeout.

Limite de connexion atteinte

Lors de l’utilisation de 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.

La connexion inter-domaines n’est pas correctement configurée

Si une connexion inter-domaines (une connexion pour laquelle l’URL SignalR n’est pas dans le même domaine que la page d’hébergement) n’est pas correctement configurée, 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) 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;

Configuration de websockets IIS pour effectuer un ping/pong pour détecter un client mort

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 à votre place. Cela garantit que votre connexion se ferme en cas d’interruption inattendue. Pour plus d’informations, consultez ce billet stackoverflow.

Autres problèmes de connexion

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

Erreur « Start must be called before data can be sent »

Cette erreur est couramment observée si le code fait référence à des objets SignalR avant le démarrage de la connexion. La connexion pour les gestionnaires et les éléments similaires qui appellent les méthodes définies sur le serveur doit être ajoutée une fois la connexion terminée. Notez que l’appel à Start étant asynchrone, le code après l’appel peut être exécuté avant sa fin. 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 qui est passée en tant que paramètre à la méthode start :

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 alors 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 un dossier appelé SignalR dans votre application ou désactivez la génération automatique de 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 à ce problème. Vérifiez toutes les opérations suivantes :

La référence d’adresse du proxy hub n’a pas été 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ée n’est pas correctement mise en forme. Vérifiez que la référence à l’adresse du hub est correctement établie. Pour plus d’informations, consultez Guide pratique pour référencer le proxy généré dynamiquement .
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 la 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 de serveur interne 500 »

Il s’agit d’une erreur très générique qui peut 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 peuvent être trouvés via le débogage du serveur. Vous pouvez obtenir des informations plus détaillées sur les erreurs en activant les 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 couramment 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 à s’assurer 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 produit si l’appel à n’est MapSignalR pas effectué correctement. Pour plus d’informations, consultez Comment inscrire SignalR Middleware et configurer les 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 descripteurs 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 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. Pour plus d’informations sur les navigateurs pouvant être utilisés avec SignalR, consultez Transports et secours .

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

Cette erreur se produit si DisableJavaScriptProxies est défini tout en incluant également une référence au proxy généré dynamiquement sur 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.

Erreur « 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 intercepté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 « TypeError non intercepté : impossible de lire la propriété '<property>' d’undefined »

Cette erreur s’explique par le fait que jQuery ou le proxy hubs ne sont pas référencés 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 antérieure à la référence au proxy hubs. La référence par défaut au proxy hubs doit se présenter comme suit :

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

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

Erreur « RuntimeBinderException a été non géré par le code utilisateur »

Cette erreur peut se produire lorsque la surcharge incorrecte de Hub.On est utilisée. 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 les sauts de connexion entre les chargements de page

Ce comportement est normal. Étant donné que l’objet hub est hébergé dans l’objet page, le hub est détruit lors de l’actualisation de la page. Une application multipage doit conserver l’association entre les utilisateurs et les ID de connexion afin qu’ils soient cohérents 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 de 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 normal.

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

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

La connexion est interrompue après l’expiration de l’authentification

Ce comportement est normal. 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 la réexécutation des scripts de chaque page, 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 la fin de l’initialisation de la page avant de démarrer la connexion.

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

Les messages sont retardés lors de l’utilisation d’événements envoyés par le serveur sur Silverlight. Pour forcer l’interrogation longue à utiliser à la place, utilisez les éléments suivants lors du 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 : <la méthode nom> de la méthode n’a pas pu être résolue » lorsque le client appelle la méthode sur le serveur

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

Erreurs de compilation et côté serveur

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

La référence à hub instance a la valeur Null

Étant donné qu’un hub instance est créé pour chaque connexion, vous ne pouvez pas créer vous-même un instance d’un hub dans votre code. Pour appeler des méthodes sur un hub à partir de l’extérieur 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 normal. 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

Cette erreur peut s’afficher si vous utilisez du code provenant 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 (comme OnConnectedAsync).

HostContextExtensions.WebSocketServerUrl a la valeur null

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

Erreur « Un itinéraire nommé 'signalr.hubs' se trouve déjà dans la collection d’itinéraires »

Cette erreur s’affiche si MapSignalR est appelé 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. Assurez-vous 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ées dans le document Plateformes prises en charge ), vous devez activer WebSocket sur votre serveur. Vous trouverez des instructions pour ce faire 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 qu’un accès incorrect est effectué. 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 sous 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 « La conversion du type 'Task(Of Object)' en type 'String' is not valid » (Conversion du type 'Task(Of Object)' en type 'String' is not valid

Pour accéder à l’état de l’appelant en 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 Explorateur de solutions

Certains de nos tutoriels vous dirigent vers le nœud « Documents de script » dans 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 normal. 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 LIÉS à IIS

Cette section contient des problèmes liés aux services Internet Information.

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 l’installation de ASP.NET sur le serveur (ASP.NET n’est pas installé sur IIS par défaut). Pour installer ASP.NET, consultez téléchargements ASP.NET.

Problèmes liés à Microsoft Azure

Cette section contient les problèmes liés à 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 fond de panier Azure après la modification des 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.

Partager via