Problembehandlung für SignalR

von Patrick Fletcher

Warnung

Diese Dokumentation gilt nicht für die neueste Version von SignalR. Sehen Sie sich ASP.NET Core SignalR an.

In diesem Dokument werden häufige Probleme mit SignalR beschrieben.

In diesem Thema verwendete Softwareversionen

• Visual Studio 2013
• .NET 4.5
• SignalR, Version 2

Frühere Versionen dieses Themas

Informationen zu früheren Versionen von SignalR finden Sie unter Ältere Versionen von SignalR.

Fragen und Kommentare

Bitte hinterlassen Sie Feedback dazu, wie Ihnen dieses Tutorial gefallen hat und was wir in den Kommentaren unten auf der Seite verbessern könnten. Wenn Sie Fragen haben, die nicht direkt mit dem Tutorial zusammenhängen, können Sie diese im ASP.NET SignalR-Forum oder StackOverflow.com posten.

Dieses Dokument enthält die folgenden Abschnitte.

• Fehler beim Aufrufen von Methoden zwischen Client und Server im Hintergrund
• Konfigurieren von IIS-Websockets mit Ping/Pong, um einen toten Client zu erkennen
• Andere Verbindungsprobleme
• Kompilierung und serverseitige Fehler
• Visual Studio-Probleme
• Probleme mit Internetinformationsdiensten
• Microsoft Azure-Probleme

Fehler beim Aufrufen von Methoden zwischen Client und Server im Hintergrund

In diesem Abschnitt werden mögliche Ursachen für einen Methodenaufruf zwischen Client und Server ohne aussagekräftige Fehlermeldung beschrieben. In einer SignalR-Anwendung verfügt der Server über keine Informationen zu den Methoden, die der Client implementiert. wenn der Server eine Clientmethode aufruft, werden der Methodenname und die Parameterdaten an den Client gesendet, und die Methode wird nur ausgeführt, wenn sie im vom Server angegebenen Format vorhanden ist. Wenn keine übereinstimmende Methode auf dem Client gefunden wird, geschieht nichts, und es wird keine Fehlermeldung auf dem Server ausgelöst.

Um die Clientmethoden weiter zu untersuchen, die nicht aufgerufen werden, können Sie die Protokollierung aktivieren, bevor die Startmethode auf dem Hub aufgerufen wird, um zu ermitteln, welche Aufrufe vom Server kommen. Informationen zum Aktivieren der Protokollierung in einer JavaScript-Anwendung finden Sie unter Aktivieren der clientseitigen Protokollierung (JavaScript-Clientversion). Informationen zum Aktivieren der Protokollierung in einer .NET-Clientanwendung finden Sie unter Aktivieren der clientseitigen Protokollierung (.NET-Clientversion).

Falsch geschriebene Methode, falsche Methodensignatur oder falscher Hubname

Wenn der Name oder die Signatur einer aufgerufenen Methode nicht genau mit einer geeigneten Methode auf dem Client übereinstimmt, schlägt der Aufruf fehl. Vergewissern Sie sich, dass der vom Server aufgerufene Methodenname mit dem Namen der Methode auf dem Client übereinstimmt. Außerdem erstellt SignalR den Hubproxy mit Camel-Case-Methoden, wie in JavaScript geeignet, sodass eine Methode namens SendMessage auf dem Server im Clientproxy aufgerufen sendMessage wird. Wenn Sie das HubName Attribut in Ihrem serverseitigen Code verwenden, überprüfen Sie, ob der verwendete Name mit dem Namen übereinstimmt, der zum Erstellen des Hubs auf dem Client verwendet wurde. Wenn Sie das HubName Attribut nicht verwenden, vergewissern Sie sich, dass der Name des Hubs in einem JavaScript-Client camel-cased ist, z. B. chatHub anstelle von ChatHub.

Doppelter Methodenname auf dem Client

Stellen Sie sicher, dass Sie keine doppelte Methode auf dem Client haben, die sich nur nach Groß- und Kleinschreibung unterscheidet. Wenn Ihre Clientanwendung über eine Methode namens verfügt sendMessage, vergewissern Sie sich, dass nicht auch eine Methode aufgerufen SendMessage wird.

Fehlender JSON-Parser auf dem Client

SignalR erfordert, dass ein JSON-Parser vorhanden ist, um Aufrufe zwischen dem Server und dem Client zu serialisieren. Wenn Ihr Client keinen integrierten JSON-Parser (z. B. Internet Explorer 7) hat, müssen Sie einen in Ihre Anwendung aufnehmen. Sie können den JSON-Parser hier herunterladen.

Mischen von Hub- und PersistentConnection-Syntax

SignalR verwendet zwei Kommunikationsmodelle: Hubs und PersistentConnections. Die Syntax zum Aufrufen dieser beiden Kommunikationsmodelle unterscheidet sich im Clientcode. Wenn Sie ihrem Servercode einen Hub hinzugefügt haben, vergewissern Sie sich, dass der gesamte Clientcode die richtige Hubsyntax verwendet.

JavaScript-Clientcode, der eine PersistentConnection in einem JavaScript-Client erstellt

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

JavaScript-Clientcode, der einen Hubproxy in einem Javascript-Client erstellt

var myHub = $.connection.MyHub;

C#-Servercode, der eine Route einer PersistentConnection zuordnet

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

C#-Servercode, der eine Route einem Hub oder mehreren Hubs ordnet, wenn Sie über mehrere Anwendungen verfügen

App.MapSignalR();

Die Verbindung wurde vor dem Hinzufügen von Abonnements gestartet

Wenn die Verbindung des Hubs gestartet wird, bevor Methoden, die vom Server aufgerufen werden können, dem Proxy hinzugefügt werden, werden keine Nachrichten empfangen. Der folgende JavaScript-Code startet den Hub nicht ordnungsgemäß:

Falscher JavaScript-Clientcode, der den Empfang von Hubs-Nachrichten nicht zulässt

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

Fügen Sie stattdessen die Methodenabonnements hinzu, bevor Sie Start aufrufen:

JavaScript-Clientcode, der abonnements zu einem Hub ordnungsgemäß hinzufügt

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

Fehlender Methodenname auf dem Hubproxy

Vergewissern Sie sich, dass die auf dem Server definierte Methode auf dem Client abonniert ist. Auch wenn der Server die -Methode definiert, muss sie dem Clientproxy trotzdem hinzugefügt werden. Methoden können dem Clientproxy auf folgende Weise hinzugefügt werden (beachten Sie, dass die Methode dem client Member des Hubs und nicht direkt dem Hub hinzugefügt wird):

JavaScript-Clientcode, der einem Hubproxy Methoden hinzufügt

// 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) {...}
});

Hub- oder Hubmethoden, die nicht als öffentlich deklariert sind

Um auf dem Client sichtbar zu sein, müssen die Hubimplementierung und -methoden als publicdeklariert werden.

Zugreifen auf hubs aus einer anderen Anwendung

Auf SignalR Hubs kann nur über Anwendungen zugegriffen werden, die SignalR-Clients implementieren. SignalR kann nicht mit anderen Kommunikationsbibliotheken (z. B. SOAP oder WCF-Webdiensten) zusammenarbeiten. Wenn für Ihre Zielplattform kein SignalR-Client verfügbar ist, können Sie nicht direkt auf den Endpunkt des Servers zugreifen.

Manuelles Serialisieren von Daten

SignalR verwendet JSON automatisch, um Ihre Methodenparameter zu serialisieren – es ist nicht erforderlich, dies selbst zu tun.

Die Remotehubmethode wird nicht auf dem Client in der OnDisconnected-Funktion ausgeführt

Dieses Verhalten ist beabsichtigt. Wenn OnDisconnected aufgerufen wird, hat der Hub bereits den Disconnected Status erreicht, wodurch es nicht zulässt, dass weitere Hubmethoden aufgerufen werden.

C#-Servercode, der Code im OnDisconnected-Ereignis ordnungsgemäß ausführt

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

OnDisconnect wird nicht zu konsistenten Zeiten ausgelöst

Dieses Verhalten ist beabsichtigt. Wenn ein Benutzer versucht, von einer Seite mit einer aktiven SignalR-Verbindung wegzu navigieren, versucht der SignalR-Client dann, den Server zu benachrichtigen, dass die Clientverbindung beendet wird. Wenn der Best-Effort-Versuch des SignalR-Clients fehlschlägt, den Server zu erreichen, entfällt die Verbindung nach einer später konfigurierbaren DisconnectTimeout Verbindung, zu der das OnDisconnected Ereignis ausgelöst wird. Wenn der Best-Effort-Versuch des SignalR-Clients erfolgreich ist, wird das OnDisconnected Ereignis sofort ausgelöst.

Informationen zum Festlegen der DisconnectTimeout Einstellung finden Sie unter Behandeln von Verbindungslebensdauerereignissen: DisconnectTimeout.

Verbindungslimit erreicht

Wenn Sie die Vollversion von IIS unter einem Clientbetriebssystem wie Windows 7 verwenden, wird ein Grenzwert von 10 Verbindungen auferlegt. Verwenden Sie bei Verwendung eines Clientbetriebssystems stattdessen IIS Express, um dieses Limit zu vermeiden.

Domänenübergreifende Verbindung nicht ordnungsgemäß eingerichtet

Wenn eine domänenübergreifende Verbindung (eine Verbindung, für die sich die SignalR-URL nicht in derselben Domäne wie die Hostingseite befindet) nicht ordnungsgemäß eingerichtet ist, kann die Verbindung ohne Fehlermeldung fehlschlagen. Informationen zum Aktivieren domänenübergreifender Kommunikation finden Sie unter Einrichten einer domänenübergreifenden Verbindung.

Verbindung mit NTLM (Active Directory) funktioniert nicht im .NET-Client

Eine Verbindung in einer .NET-Clientanwendung, die Domänensicherheit verwendet, schlägt möglicherweise fehl, wenn die Verbindung nicht ordnungsgemäß konfiguriert ist. Um SignalR in einer Domänenumgebung zu verwenden, legen Sie die erforderliche Verbindungseigenschaft wie folgt fest:

C#-Clientcode, der Verbindungsanmeldeinformationen implementiert

connection.Credentials = CredentialCache.DefaultCredentials;

Konfigurieren von IIS-Websockets mit Ping/Pong, um einen toten Client zu erkennen

SignalR-Server wissen nicht, ob der Client tot ist oder nicht, und sie verlassen sich auf Benachrichtigungen des zugrunde liegenden Websockets für Verbindungsfehler, d. h. den OnClose Rückruf. Eine Lösung für dieses Problem besteht darin, IIS-Websockets zu konfigurieren, um das Ping/Pong für Sie zu erledigen. Dadurch wird sichergestellt, dass Ihre Verbindung geschlossen wird, wenn sie unerwartet unterbrochen wird. Weitere Informationen finden Sie in diesem Stackoverflow-Beitrag.

Andere Verbindungsprobleme

In diesem Abschnitt werden die Ursachen und Lösungen für bestimmte Symptome oder Fehlermeldungen beschrieben, die während einer Verbindung auftreten.

Fehler "Start muss aufgerufen werden, bevor Daten gesendet werden können"

Dieser Fehler tritt häufig auf, wenn Code auf SignalR-Objekte verweist, bevor die Verbindung gestartet wird. Die Drahtverbindung für Handler und dergleichen, die methoden aufruft, die auf dem Server definiert sind, müssen nach Abschluss der Verbindung hinzugefügt werden. Beachten Sie, dass der Aufruf von Start asynchron ist, sodass Code nach dem Aufruf ausgeführt werden kann, bevor er abgeschlossen wird. Die beste Möglichkeit, Handler hinzuzufügen, nachdem eine Verbindung vollständig gestartet wurde, besteht darin, sie in einer Rückruffunktion zu platzieren, die als Parameter an die start-Methode übergeben wird:

JavaScript-Clientcode, der Ereignishandler richtig hinzufügt, die auf SignalR-Objekte verweisen

$.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();
    });

Dieser Fehler wird auch angezeigt, wenn eine Verbindung beendet wird, während auf SignalR-Objekte noch verwiesen wird.

Fehler "301 dauerhaft verschoben" oder "302 vorübergehend verschoben"

Dieser Fehler kann auftreten, wenn das Projekt einen Ordner namens SignalR enthält, der den automatisch erstellten Proxy beeinträchtigt. Um diesen Fehler zu vermeiden, verwenden Sie keinen Ordner namens SignalR in Ihrer Anwendung, oder deaktivieren Sie die automatische Proxygenerierung. Weitere Informationen finden Sie unter Der generierte Proxy und seine Aufgaben .

Fehler "403 Verboten" in .NET oder Silverlight-Client

Dieser Fehler kann in domänenübergreifenden Umgebungen auftreten, in denen die domänenübergreifende Kommunikation nicht ordnungsgemäß aktiviert ist. Informationen zum Aktivieren der domänenübergreifenden Kommunikation finden Sie unter Herstellen einer domänenübergreifenden Verbindung. Informationen zum Herstellen einer domänenübergreifenden Verbindung in einem Silverlight-Client finden Sie unter Domänenübergreifende Verbindungen von Silverlight-Clients.

Fehler "404 nicht gefunden"

Es gibt mehrere Ursachen für dieses Problem. Überprüfen Sie folgendes:

• Der Verweis auf die Hubproxyadresse wurde nicht ordnungsgemäß formatiert: Dieser Fehler tritt häufig auf, wenn der Verweis auf die generierte Hubproxyadresse nicht ordnungsgemäß formatiert ist. Stellen Sie sicher, dass der Verweis auf die Hubadresse ordnungsgemäß erfolgt ist. Ausführliche Informationen finden Sie unter Verweisen auf den dynamisch generierten Proxy .

• Hinzufügen von Routen zur Anwendung vor dem Hinzufügen der Hubroute: Wenn Ihre Anwendung andere Routen verwendet, überprüfen Sie, ob die erste hinzugefügte Route der Aufruf von MapSignalRist.

• Verwenden von IIS 7 oder 7.5 ohne Update für erweiterungslose URLs: Die Verwendung von IIS 7 oder 7.5 erfordert ein Update für erweiterungslose URLs, damit der Server Zugriff auf die Hubdefinitionen unter /signalr/hubsgewähren kann. Das Update finden Sie hier.

• IIS-Cache veraltet oder beschädigt: Um zu überprüfen, ob der Cacheinhalt nicht veraltet ist, geben Sie den folgenden Befehl in ein PowerShell-Fenster ein, um den Cache zu löschen:

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

"500 Interner Serverfehler"

Dies ist ein sehr allgemeiner Fehler, der eine Vielzahl von Ursachen haben kann. Die Details des Fehlers sollten im Ereignisprotokoll des Servers angezeigt oder über das Debuggen des Servers gefunden werden. Ausführlichere Fehlerinformationen erhalten Sie, indem Sie detaillierte Fehler auf dem Server aktivieren. Weitere Informationen finden Sie unter Behandeln von Fehlern in der Hub-Klasse.

Dieser Fehler tritt auch häufig auf, wenn eine Firewall oder ein Proxy nicht ordnungsgemäß konfiguriert ist, sodass die Anforderungsheader neu geschrieben werden. Die Lösung besteht darin, sicherzustellen, dass Port 80 in der Firewall oder dem Proxy aktiviert ist.

"Unerwarteter Antwortcode: 500"

Dieser Fehler kann auftreten, wenn die in der Anwendung verwendete Version von .NET Framework nicht mit der in Web.Config angegebenen Version übereinstimmt. Die Lösung besteht darin, zu überprüfen, ob .NET 4.5 sowohl in den Anwendungseinstellungen als auch in der Web.Config-Datei verwendet wird.

Fehler "TypeError: <hubType> ist undefined"

Dieser Fehler tritt auf, wenn der Aufruf von MapSignalR nicht ordnungsgemäß erfolgt. Weitere Informationen finden Sie unter Registrieren von SignalR-Middleware und Konfigurieren von SignalR-Optionen .

JsonSerializationException wurde vom Benutzercode nicht behandelt

Stellen Sie sicher, dass die Parameter, die Sie an Ihre Methoden senden, keine nicht serialisierbaren Typen enthalten (z. B. Dateihandles oder Datenbankverbindungen). Wenn Sie Elemente für ein serverseitiges Objekt verwenden müssen, das nicht an den Client gesendet werden soll (aus Sicherheitsgründen oder aus Serialisierungsgründen), verwenden Sie das JSONIgnore -Attribut.

Fehler "Protokollfehler: Unbekannter Transport"

Dieser Fehler kann auftreten, wenn der Client die von SignalR verwendeten Transporte nicht unterstützt. Unter Transporte und Fallbacks finden Sie Informationen dazu, welche Browser mit SignalR verwendet werden können.

"Die JavaScript Hub-Proxygenerierung wurde deaktiviert."

Dieser Fehler tritt auf, wenn DisableJavaScriptProxies festgelegt ist, während gleichzeitig ein Verweis auf den dynamisch generierten Proxy unter signalr/hubseingeschlossen wird. Weitere Informationen zum manuellen Erstellen des Proxys finden Sie unter Der generierte Proxy und was er für Sie tut.

Fehler "Die Verbindungs-ID hat das falsche Format" oder "Die Benutzeridentität kann sich während einer aktiven SignalR-Verbindung nicht ändern"

Dieser Fehler kann auftreten, wenn die Authentifizierung verwendet wird und der Client abgemeldet wird, bevor die Verbindung beendet wird. Die Lösung besteht darin, die SignalR-Verbindung vor dem Abmelden des Clients zu beenden.

"Uncaught Error: SignalR: jQuery not found. Stellen Sie sicher, dass vor dem Fehler "SignalR.js Datei" auf jQuery verwiesen wird.

Für den SignalR-JavaScript-Client ist jQuery erforderlich. Vergewissern Sie sich, dass Ihr Verweis auf jQuery richtig ist, dass der verwendete Pfad gültig ist und dass der Verweis auf jQuery vor dem Verweis auf SignalR liegt.

Fehler "Uncaught TypeError: Eigenschaft '<Property>' kann nicht gelesen werden"

Dieser Fehler tritt darauf auf, dass nicht ordnungsgemäß auf jQuery oder den Hubs-Proxy verwiesen wurde. Vergewissern Sie sich, dass Ihr Verweis auf jQuery und den Hubs-Proxy korrekt ist, dass der verwendete Pfad gültig ist und dass der Verweis auf jQuery vor dem Verweis auf den Hubs-Proxy liegt. Der Standardverweis auf den Hubs-Proxy sollte wie folgt aussehen:

Clientseitiger HTML-Code, der ordnungsgemäß auf den Hubs-Proxy verweist

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

Fehler "RuntimeBinderException wurde vom Benutzercode nicht behandelt"

Dieser Fehler kann auftreten, wenn die falsche Überladung von Hub.On verwendet wird. Wenn die Methode über einen Rückgabewert verfügt, muss der Rückgabetyp als generischer Typparameter angegeben werden:

Auf dem Client definierte Methode (ohne generierten Proxy)

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

Verbindungs-ID ist inkonsistent, oder Verbindungsunterbrechungen zwischen Seitenladevorgängen

Dieses Verhalten ist beabsichtigt. Da das Hubobjekt im Seitenobjekt gehostet wird, wird der Hub zerstört, wenn die Seite aktualisiert wird. Eine mehrseitige Anwendung muss die Zuordnung zwischen Benutzern und Verbindungs-IDs beibehalten, damit sie zwischen Seitenladevorgängen konsistent sind. Die Verbindungs-IDs können auf dem Server entweder in einem ConcurrentDictionary Objekt oder in einer Datenbank gespeichert werden.

Fehler "Der Wert darf nicht NULL sein"

Serverseitige Methoden mit optionalen Parametern werden derzeit nicht unterstützt. Wenn der optionale Parameter weggelassen wird, schlägt die Methode fehl. Weitere Informationen finden Sie unter Optionale Parameter.

Fehler "Firefox kann keine Verbindung mit dem Server unter <Adresse> herstellen" in Firebug

Diese Fehlermeldung wird in Firebug angezeigt, wenn die Aushandlung des WebSocket-Transports fehlschlägt und stattdessen ein anderer Transport verwendet wird. Dieses Verhalten ist beabsichtigt.

Fehler "Das Remotezertifikat ist gemäß der Validierungsprozedur ungültig" in der .NET-Clientanwendung

Wenn Ihr Server benutzerdefinierte Clientzertifikate erfordert, können Sie der Verbindung vor der Anforderung ein x509certificate hinzufügen. Fügen Sie das Zertifikat der Verbindung mithilfe von Connection.AddClientCertificatehinzu.

Verbindungsabbrüche nach Authentifizierungstimeout

Dieses Verhalten ist beabsichtigt. Authentifizierungsanmeldeinformationen können nicht geändert werden, während eine Verbindung aktiv ist. Zum Aktualisieren der Anmeldeinformationen muss die Verbindung beendet und neu gestartet werden.

OnConnected wird bei Verwendung von jQuery Mobile zweimal aufgerufen.

Die Funktion von initializePage jQuery Mobile erzwingt, dass die Skripts auf jeder Seite erneut ausgeführt werden, wodurch eine zweite Verbindung hergestellt wird. Lösungen für dieses Problem sind:

• Schließen Sie den Verweis auf jQuery Mobile vor Ihrer JavaScript-Datei ein.
• Deaktivieren Sie die initializePage Funktion, indem Sie festlegen $.mobile.autoInitializePage = false.
• Warten Sie, bis die Seite initialisiert wurde, bevor Sie die Verbindung starten.

Nachrichten werden in Silverlight-Anwendungen mithilfe von gesendeten Serverereignissen verzögert

Nachrichten werden verzögert, wenn servergesendete Ereignisse in Silverlight verwendet werden. Um zu erzwingen, dass stattdessen lange Abrufe verwendet werden, verwenden Sie beim Starten der Verbindung Folgendes:

connection.Start(new LongPollingTransport());

"Berechtigung verweigert" mithilfe des Forever Frame-Protokolls

Dies ist ein bekanntes Problem, das hier beschrieben wird. Dieses Symptom kann mit der neuesten JQuery-Bibliothek beobachtet werden. Die Problemumgehung besteht darin, Ihre Anwendung auf JQuery 1.8.2 herabzustufen.

"InvalidOperationException: Keine gültige Websocketanforderung.

Dieser Fehler kann auftreten, wenn das WebSocket-Protokoll verwendet wird, aber der Netzwerkproxy die Anforderungsheader ändert. Die Lösung besteht darin, den Proxy so zu konfigurieren, dass WebSocket an Port 80 zugelassen wird.

"Ausnahme: <Methodennamenmethode> konnte nicht aufgelöst werden", wenn der Client die Methode auf dem Server aufruft

Dieser Fehler kann durch die Verwendung von Datentypen verursacht werden, die nicht in einer JSON-Nutzlast ermittelt werden können, z. B. Array. Die Problemumgehung besteht darin, einen Datentyp zu verwenden, der von JSON erkannt werden kann, z. B. IList. Weitere Informationen finden Sie unter .NET-Client kann Hubmethoden mit Arrayparametern nicht aufrufen.

Kompilierung und serverseitige Fehler

Der folgende Abschnitt enthält mögliche Lösungen für Compiler- und serverseitige Laufzeitfehler.

Verweis auf hub instance ist NULL

Da für jede Verbindung ein Hub instance erstellt wird, können Sie keine instance eines Hubs in Ihrem Code selbst erstellen. Informationen zum Aufrufen von Methoden auf einem Hub von außerhalb des Hubs selbst finden Sie unter Aufrufen von Clientmethoden und Verwalten von Gruppen von außerhalb der Hub-Klasse. Informationen zum Abrufen eines Verweises auf den Hubkontext finden Sie unter Aufrufen von Clientmethoden und Verwalten von Gruppen von außerhalb der Hubklasse .

HTTPContext.Current.Session ist NULL

Dieses Verhalten ist beabsichtigt. SignalR unterstützt den ASP.NET Sitzungszustand nicht, da die Aktivierung des Sitzungszustands das Duplexmessaging unterbrechen würde.

Keine geeignete Methode zum Überschreiben

Dieser Fehler wird möglicherweise angezeigt, wenn Sie Code aus älteren Dokumentationen oder Blogs verwenden. Stellen Sie sicher, dass Sie nicht auf Namen von Methoden verweisen, die geändert oder veraltet sind (z OnConnectedAsync. B. ).

HostContextExtensions.WebSocketServerUrl ist NULL

Dieses Verhalten ist beabsichtigt. Dieser Member ist veraltet und sollte nicht verwendet werden.

Fehler "Eine Route mit dem Namen 'signalr.hubs' ist bereits in der Routensammlung enthalten"

Dieser Fehler wird angezeigt, wenn MapSignalR ihre Anwendung zweimal aufgerufen wird. Einige Beispielanwendungen rufen MapSignalR direkt in der Startup-Klasse auf, andere führen den Aufruf in einer Wrapperklasse durch. Stellen Sie sicher, dass Ihre Anwendung nicht beides ausführt.

WebSocket wird nicht verwendet.

Wenn Sie überprüft haben, ob Ihr Server und Ihre Clients die Anforderungen für WebSocket erfüllen (siehe Dokument Unterstützte Plattformen ), müssen Sie WebSocket auf Ihrem Server aktivieren. Anweisungen hierzu finden Sie hier.

$.connection ist nicht definiert.

Dieser Fehler gibt an, dass entweder die Skripts auf einer Seite nicht ordnungsgemäß geladen werden oder dass der Hubproxy nicht erreichbar ist oder nicht ordnungsgemäß darauf zugegriffen wird. Vergewissern Sie sich, dass die Skriptverweise auf Ihrer Seite den in Ihr Projekt geladenen Skripts entsprechen und dass /signalr/hubs in einem Browser zugegriffen werden kann, wenn der Server ausgeführt wird.

Mindestens ein Typ, der zum Kompilieren eines dynamischen Ausdrucks erforderlich ist, wurde nicht gefunden.

Dieser Fehler gibt an, dass die Microsoft.CSharp Bibliothek fehlt. Fügen Sie es auf der Registerkarte Assemblys-Framework> hinzu.

Der Aufruferstatus kann nicht über Clients.Caller in Visual Basic oder in einem stark typisierten Hub zugegriffen werden. Fehler "Konvertierung vom Typ 'Task(Of Object)' in den Typ 'String' ist ungültig"

Verwenden Sie für den Zugriff auf den Aufruferstatus in Visual Basic oder in einem stark typisierten Hub die Clients.CallerState -Eigenschaft (eingeführt in SignalR 2.1) anstelle von Clients.Caller.

Visual Studio-Probleme

In diesem Abschnitt werden Probleme beschrieben, die in Visual Studio auftreten.

Der Knoten "Skriptdokumente" wird in Projektmappen-Explorer nicht angezeigt.

Einige unserer Tutorials leiten Sie beim Debuggen zum Knoten "Skriptdokumente" in Projektmappen-Explorer weiter. Dieser Knoten wird vom JavaScript-Debugger erstellt und nur beim Debuggen von Browserclients im Internet Explorer angezeigt. Der Knoten wird nicht angezeigt, wenn Chrome oder Firefox verwendet wird. Der JavaScript-Debugger wird auch nicht ausgeführt, wenn ein anderer Clientdebugger ausgeführt wird, z. B. der Silverlight-Debugger.

SignalR funktioniert nicht in Visual Studio 2008 oder früher

Dieses Verhalten ist beabsichtigt. SignalR erfordert .NET Framework 4 oder höher. Hierfür müssen SignalR-Anwendungen in Visual Studio 2010 oder höher entwickelt werden. Die Serverkomponente von SignalR erfordert .NET Framework 4.5.

IIS-Probleme

Dieser Abschnitt enthält Probleme mit Internetinformationsdiensten.

SignalR funktioniert auf dem Visual Studio-Entwicklungsserver, aber nicht in IIS.

SignalR wird in IIS 7.0 und 7.5 unterstützt, es muss jedoch unterstützung für erweiterungslose URLs hinzugefügt werden. Informationen zum Hinzufügen von Unterstützung für erweiterungslose URLs finden Sie unter https://support.microsoft.com/kb/980368

SignalR erfordert, dass ASP.NET auf dem Server installiert ist (ASP.NET ist nicht standardmäßig auf IIS installiert). Informationen zum Installieren ASP.NET finden Sie unter ASP.NET Downloads.

Microsoft Azure-Probleme

Dieser Abschnitt enthält Probleme mit Microsoft Azure.

FileLoadException beim Hosten von SignalR in einer Azure-Workerrolle

Das Hosten von SignalR in einer Azure-Workerrolle kann zu der Ausnahme "Datei oder Assembly 'Microsoft.Owin, Version=2.0.0.0.0" führen. Dies ist ein bekanntes Problem mit NuGet. Bindungsumleitungen werden in Azure-Workerrollenprojekten nicht automatisch hinzugefügt. Um dies zu beheben, können Sie die Bindungsumleitungen manuell hinzufügen. Fügen Sie der Datei für Ihr Workerrollenprojekt die app.config folgenden Zeilen hinzu.

<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>

Nachrichten werden nach dem Ändern von Themennamen nicht über die Azure-Backplane empfangen.

Die von der Azure-Backplane verwendeten Themen werden intern verwaltet. Sie sollen nicht vom Benutzer konfiguriert werden.