Problembehandlung bei SignalR

von Patrick Fletcher

Warnung

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

In diesem Dokument werden allgemeine Problembehandlungsprobleme mit SignalR beschrieben.

In diesem Thema verwendete Softwareversionen

Frühere Versionen dieses Themas

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

Fragen und Kommentare

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

Dieses Dokument enthält die folgenden Abschnitte.

Das Aufrufen von Methoden zwischen Client und Server schlägt unbemerkt fehl.

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 Clientmethoden, die nicht aufgerufen werden, weiter zu untersuchen, können Sie die Protokollierung aktivieren, bevor Sie die Startmethode auf dem Hub aufrufen, um zu sehen, welche Aufrufe vom Server stammen. 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 exakt mit einer geeigneten Methode auf dem Client übereinstimmt, schlägt der Aufruf fehl. Stellen Sie sicher, dass der vom Server aufgerufene Methodenname mit dem Namen der Methode auf dem Client übereinstimmt. Außerdem erstellt SignalR den Hub-Proxy mithilfe von Camel-Case-Methoden, wie es für JavaScript üblich ist, sodass eine Methode, die auf dem Server als SendMessage aufgerufen wird, im Client-Proxy als sendMessage aufgerufen wird. Wenn Sie das HubName Attribut im serverseitigen Code verwenden, überprüfen Sie, ob der verwendete Name dem Namen entspricht, der zum Erstellen des Hubs auf dem Client verwendet wird. Wenn Sie das HubName Attribut nicht verwenden, überprüfen Sie, ob der Name des Hubs im JavaScript-Client camel-cased ist, z. B. chatHub anstelle von ChatHub.

Doppelter Methodenname auf dem Client

Vergewissern Sie sich, dass Sie nicht über eine doppelte Methode auf dem Client verfügen, die sich nur in der Groß- und Kleinschreibung unterscheidet. Wenn Ihre Clientanwendung eine Methode namens sendMessage hat, vergewissern Sie sich, dass es nicht auch eine Methode namens SendMessage gibt.

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) aufweist, müssen Sie einen in Ihre Anwendung einschließen. Hier können Sie den JSON-Parser 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 einen Hub in Ihrem Servercode hinzugefügt haben, überprüfen Sie, ob 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 zu einer PersistentConnection ordnet

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

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

App.MapSignalR();

Verbindung gestartet, bevor Abonnements hinzugefügt werden

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 nicht zulässt, dass Hub-Nachrichten empfangen werden

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

Fügen Sie stattdessen die Methodenabonnements vor dem Aufrufen von "Start" hinzu:

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

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

Fehlender Methodenname im Hubproxy

Stellen Sie sicher, dass die auf dem Server definierte Methode auf dem Client abonniert ist. Obwohl der Server die Methode definiert, muss sie dem Clientproxy weiterhin hinzugefügt werden. Methoden können dem Clientproxy auf folgende Weise hinzugefügt werden (Beachten Sie, dass die Methode dem client Mitglied des Hubs und nicht dem Hub direkt hinzugefügt wird):

JavaScript-Clientcode, der Methoden zu einem Hubproxy 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 Public deklariert wurden

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

Zugriff auf Hub von 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 kein SignalR-Client für Ihre Zielplattform 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, sie selbst zu erledigen.

Remote Hub-Methode, die nicht auf dem Client in der OnDisconnected-Funktion ausgeführt wird

Dieses Verhalten ist beabsichtigt. Wenn OnDisconnected aufgerufen wird, ist der Hub bereits in den Disconnected Zustand übergegangen, daher können keine weiteren 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 zu konsistenten Zeiten nicht ausgelöst

Dieses Verhalten ist beabsichtigt. Wenn ein Benutzer versucht, von einer Seite mit einer aktiven SignalR-Verbindung zu navigieren, versucht der SignalR-Client dann, den Server zu benachrichtigen, dass die Clientverbindung beendet wird. Wenn der Best-Effort-Versuch des SignalR-Clients den Server nicht erreicht, wird der Server nach einem konfigurierbaren DisconnectTimeout die Verbindung entsorgen, wird das OnDisconnected Ereignis ausgelöst. 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.

Verbindungsgrenze erreicht

Wenn Sie die Vollversion von IIS auf einem Clientbetriebssystem wie Windows 7 verwenden, wird ein Grenzwert für 10 Verbindungen auferlegt. Wenn Sie ein Clientbetriebssystem verwenden, verwenden Sie stattdessen IIS Express, um diesen Grenzwert 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, schlägt die Verbindung möglicherweise ohne Fehlermeldung fehl. Informationen zum Aktivieren der domänenübergreifenden Kommunikation finden Sie unter Einrichten einer domänenübergreifenden Verbindung.

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

Eine Verbindung in einer .NET-Clientanwendung, die Domänensicherheit verwendet, kann fehlschlagen, 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 auf Ping/Pong zum Erkennen eines toten Clients

SignalR-Server wissen nicht, ob der Client tot ist oder nicht, und sie verlassen sich auf Benachrichtigungen vom zugrunde liegenden Websocket für Verbindungsfehler, d. h. den OnClose Rückruf. Eine Lösung für dieses Problem besteht darin, IIS-Websockets so zu konfigurieren, dass der Ping/Pong für Sie ausgeführt wird. Dadurch wird sichergestellt, dass die 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 wird häufig angezeigt, wenn Code auf SignalR-Objekte verweist, bevor die Verbindung gestartet wird. Die Verknüpfung der Handler und ähnlicher Elemente, die Methoden auf dem Server aufrufen, muss nach dem Herstellen der Verbindung hinzugefügt werden. Beachten Sie, dass der Aufruf von Start asynchron ist, sodass der Code möglicherweise schon vor dessen Abschluss ausgeführt wird. Die beste Möglichkeit, Handler hinzuzufügen, nachdem eine Verbindung vollständig gestartet wurde, besteht darin, sie in eine Rückruffunktion einzufügen, die als Parameter an die Startmethode ü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 immer noch verwiesen wird.

Fehler "301 Dauerhaft verschoben" oder "302 Vorübergehend verschoben"

Dieser Fehler kann angezeigt werden, 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 mit der Bezeichnung SignalR in Ihrer Anwendung oder deaktivieren Sie die automatische Proxygenerierung. Weitere Informationen finden Sie unter "Generierter Proxy" und deren Funktion .

Fehler "403 Verboten" im .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 Einrichten 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"

Für dieses Problem gibt es mehrere Ursachen. Überprüfen Sie alle folgenden Punkte:

  • Der Proxyadressenverweis des Hubs wurde nicht richtig formatiert: Dieser Fehler wird häufig angezeigt, wenn der Verweis auf die generierte Hubproxyadresse nicht ordnungsgemäß formatiert ist. Stellen Sie sicher, dass der Verweis auf die Hubadresse ordnungsgemäß erfolgt. Siehe Wie man auf den dynamisch generierten Proxy verweist für Details.

  • Hinzufügen von Routen zur Anwendung vor dem Hinzufügen der Hubroute: Wenn Ihre Anwendung andere Routen verwendet, stellen Sie sicher, dass die erste hinzugefügte Route der Anruf MapSignalRist.

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

  • IIS-Cache nicht mehr aktuell oder beschädigt: Um zu überprüfen, ob der Cacheinhalt nicht mehr aktuell 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 könnte. Die Details des Fehlers sollten im Ereignisprotokoll des Servers angezeigt werden oder über das Debuggen des Servers gefunden werden. Detailliertere Fehlerinformationen können abgerufen werden, indem die detaillierte Fehlerberichterstattung auf dem Server aktiviert wird. Weitere Informationen finden Sie unter Behandeln von Fehlern in der Hub-Klasse.

Dieser Fehler wird auch häufig angezeigt, wenn eine Firewall oder ein Proxy nicht ordnungsgemäß konfiguriert ist, wodurch 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 Datei "Web.Config" verwendet wird.

Fehler "TypeError: <hubType> ist nicht definiert"

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

JsonSerializationException wurde nicht vom Benutzercode 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 Gründen der Serialisierung), verwenden Sie das JSONIgnore Attribut.

Protokollfehler: Unbekannter Transportfehler

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

"Die JavaScript Hub-Proxygenerierung wurde deaktiviert."

Dieser Fehler tritt auf, wenn DisableJavaScriptProxies festgelegt wird, während gleichzeitig ein Verweis auf den dynamisch generierten Proxy bei signalr/hubs enthalten ist. Weitere Informationen zum manuellen Erstellen des Proxys finden Sie unter Dem generierten Proxy und seiner Funktionsweise.

"Die Verbindungs-ID weist das falsche Format auf" oder "Die Benutzeridentität kann während einer aktiven SignalR-Verbindung nicht geändert werden"

Dieser Fehler kann angezeigt werden, wenn die Authentifizierung verwendet wird und der Client abgemeldet wird, bevor die Verbindung beendet wird. Die Lösung besteht darin, die SignalR-Verbindung zu beenden, bevor der Client abgemeldet wird.

Uncaught Error: SignalR: jQuery nicht gefunden. Stellen Sie sicher, dass jQuery vor dem Fehler "SignalR.js Datei" referenziert wird.

Der SignalR-JavaScript-Client erfordert die Ausführung von jQuery. Vergewissern Sie sich, dass ihr Verweis auf jQuery korrekt 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>' von undefined kann nicht gelesen werden'

Dieser Fehler führt dazu, dass jQuery oder der Hubproxy nicht ordnungsgemäß referenziert wurde. Vergewissern Sie sich, dass Ihr Verweis auf jQuery und der 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 Hubproxy sollte wie folgt aussehen:

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

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

Fehler "RuntimeBinderException wurde von Benutzercode nicht behandelt"

Dieser Fehler kann auftreten, wenn eine 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);

Die Verbindungs-ID ist inkonsistent oder die Verbindung bricht zwischen den Seitenladevorgängen ab.

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 entweder in einem ConcurrentDictionary Objekt oder in einer Datenbank auf dem Server gespeichert werden.

Fehler "Wert darf nicht null sein"

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

"Firefox kann keine Verbindung mit dem Server an <adresse> herstellen" Fehler in Firebug

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

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

Wenn Ihr Server benutzerdefinierte Clientzertifikate benötigt, können Sie der Verbindung vor der Anforderung ein x509certificate hinzufügen. Fügen Sie das Zertifikat zur Verbindung mithilfe von Connection.AddClientCertificate hinzu.

Die Verbindung fällt nach dem Ablauf der Authentifizierungszeit aus.

Dieses Verhalten ist beabsichtigt. Authentifizierungsanmeldeinformationen können nicht geändert werden, während eine Verbindung aktiv ist; um Anmeldeinformationen zu aktualisieren, muss die Verbindung beendet und neu gestartet werden.

OnConnected wird zweimal aufgerufen, wenn jQuery Mobile verwendet wird

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

  • Fügen Sie den Verweis auf jQuery Mobile vor der JavaScript-Datei hinzu.
  • Deaktivieren Sie die initializePage Funktion durch Festlegen $.mobile.autoInitializePage = false.
  • Warten Sie, bis die Seite die Initialisierung abgeschlossen hat, bevor Sie die Verbindung starten.

Nachrichten werden in Silverlight-Anwendungen mit Server-gesendeten Ereignissen verzögert.

Nachrichten werden verzögert, wenn Server-gesendete Ereignisse in Silverlight verwendet werden. Um stattdessen Long Polling zu erzwingen, verwenden Sie beim Starten der Verbindung die folgende Anweisung:

connection.Start(new LongPollingTransport());

"Zugriff verweigert" mithilfe des Forever Frame-Protokolls

Dies ist ein bekanntes Problem, das hier beschrieben wird. Dieses Symptom kann mit der neuesten JQuery-Bibliothek gesehen 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 auf Port 80 zulässig ist.

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

Dieser Fehler kann sich aus der Verwendung von Datentypen ergeben, die nicht in einer JSON-Nutzlast erkannt 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.

Der Verweis auf die Hub-Instanz ist null.

Da für jede Verbindung eine Hubinstanz erstellt wird, können Sie keine Instanz 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 Hubklasse , um einen Verweis auf den Hubkontext abzurufen.

HTTPContext.Current.Session ist null

Dieses Verhalten ist beabsichtigt. SignalR unterstützt den ASP.NET Sitzungszustand nicht, da die Aktivierung des Sitzungszustands die Duplexnachrichten 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. B OnConnectedAsync. ).

HostContextExtensions.WebSocketServerUrl ist null

Dieses Verhalten ist beabsichtigt. Dieses Mitglied ist veraltet und sollte nicht verwendet werden.

Fehler "Eine Route mit dem Namen "signalr.hubs" befindet sich bereits in der Routensammlung.

Dieser Fehler wird angezeigt, wenn MapSignalR von Ihrer Anwendung zweimal aufgerufen wird. Einige Beispielanwendungen rufen MapSignalR direkt in der Startup-Klasse auf; andere machen den Aufruf in einer Wrapper-Klasse. 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 (im Dokument " Unterstützte Plattformen " aufgeführt), müssen Sie WebSocket auf Ihrem Server aktivieren. Anweisungen dazu finden Sie hier.

$.connection ist nicht definiert.

Dieser Fehler gibt an, dass entweder die Skripts auf einer Seite nicht ordnungsgemäß geladen werden, oder der Hubproxy ist nicht erreichbar oder falsch zugegriffen wird. Stellen Sie sicher, dass die Skriptverweise auf Ihrer Seite den in Ihrem Projekt geladenen Skripts entsprechen und dass /signalr/hubs in einem Browser aufgerufen werden können, 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 "Assemblies-Framework>" hinzu.

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

Um auf den Aufruferstatus in Visual Basic oder in einem stark typisierten Hub zuzugreifen, verwenden Sie 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 aufgetreten sind.

Der Knoten "Skriptdokumente" wird im Lösungs-Explorer nicht angezeigt.

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

SignalR funktioniert in Visual Studio 2008 oder früheren Versionen nicht

Dieses Verhalten ist beabsichtigt. SignalR erfordert .NET Framework 4 oder höher; Dies erfordert, dass 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 den Internetinformationsdiensten.

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

SignalR wird in IIS 7.0 und 7.5 unterstützt, die Unterstützung für erweiterungslose URLs muss jedoch 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 werden muss (ASP.NET ist standardmäßig nicht auf IIS installiert). Informationen zum Installieren von 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-Worker-Rolle kann zur Ausnahme "Datei oder Assembly 'Microsoft.Owin, Version=2.0.0.0' konnte nicht geladen werden" führen. Dies ist ein bekanntes Problem mit NuGet; Bindungsumleitungen werden in Azure Worker Role-Projekten nicht automatisch hinzugefügt. Um dies zu beheben, können Sie die Bindungsumleitungen manuell hinzufügen. Fügen Sie die folgenden Zeilen zur app.config Datei für Ihr Worker Role-Projekt 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 den Azure-Backplane empfangen.

Die vom Azure-Backplane verwendeten Themen werden intern verwaltet; sie sind nicht für die Benutzer konfigurierbar.

  • Last updated on