Signalr: Optionale Parameter

Wir können die Methodenauflösung intelligenter gestalten.

Auf jeden Fall eine gute Idee. Begann tatsächlich daran zu arbeiten, kehrte aber zurück, um die grundlegende Implementierung der dynamischen Hubs zu diesem Zeitpunkt so schnell wie möglich voranzutreiben.

Apropos Methodenauflösung ...
Mit der aktuellen Implementierung könnten wir auch Unterstützung für Methodenüberladungen hinzufügen. Das Auflösen benannter Parameter könnte ebenfalls hinzugefügt werden, dies würde jedoch einige Änderungen an der tatsächlichen Übergabe der Parameter zwischen Client und Server bedeuten (Übergabe von Schlüssel-Wert-Paaren anstelle von nur Werten). Was hast du gedacht?

Gilt dies auch für einen Nullable-Parameter? Ich habe eine Methode mit 3 Parametern, von denen der letzte ein nullbares int (int?) Ist. Wenn ich den letzten Parameter auf null setze, erhalte ich die Ausnahme:

Der Wert kann nicht Null sein.
Parametername: o

at Newtonsoft.Json.Utilities.ValidationUtils.ArgumentNotNull (Objektwert, String parameterName)
bei Newtonsoft.Json.Linq.JToken.FromObjectInternal (Objekt o, JsonSerializer jsonSerializer)
bei Newtonsoft.Json.Linq.JToken.FromObject (Objekt o, JsonSerializer jsonSerializer)
bei Microsoft.AspNet.SignalR.Client.Hubs.HubProxy.Invoke T.
bei GeoTag.App.Core.Services.SignalRClientService.d__9.MoveNext ()

Beachten Sie, dass ich auf dem Server keinen Standardwert dafür festgelegt habe

Wir werden dies als v3-Kandidat in das neue Repo verschieben

@ JasonBSteele - Ich weiß, es ist eine Weile her, aber das Problem, das Sie erwähnen, wurde gerade behoben. Erwarten Sie es in der nächsten Version.

Ich bin verwirrt über den Status dieses Problems. Wurde es in einer SignalR-Version behoben?

@ Paulirwin Nr

...

Das Update ist in 2.2.1 enthalten, das im Juli ausgeliefert wurde (https://github.com/SignalR/SignalR/releases/tag/2.2.1).

Ich habe erneut getestet, was mir gestern begegnet ist. Hier sind meine Ergebnisse:
Hub-Methode, die der Client aufruft

public async Task EpicMethod( int? daysTillNETStandard20 ) {}

Aufrufversuche für .NET-Client-Server-Methoden:

1. await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), null).ConfigureAwait(false);

System.ArgumentNullException: Value cannot be null.
Parameter name: args
   at Microsoft.AspNet.SignalR.Client.Hubs.HubProxy.Invoke[TResult,TProgress](String method, Action`1 onProgress, Object[] args)
   at Microsoft.AspNet.SignalR.Client.Hubs.HubProxy.Invoke(String method, Object[] args)

2. await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), null, null).ConfigureAwait(false);

System.InvalidOperationException: 'EpicMethod' method could not be resolved. Potential candidates are: 
EpicMethod(daysTillNETStandard20:Nullable`1):Task

3. await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), null, new object[] {}).ConfigureAwait(false);

System.InvalidOperationException: 'EpicMethod' method could not be resolved. Potential candidates are: 
EpicMethod(daysTillNETStandard20:Nullable`1):Task
4. await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), null, new object[] {null}).ConfigureAwait(false);
System.InvalidOperationException: 'EpicMethod' method could not be resolved. Potential candidates are: 
EpicMethod(daysTillNETStandard20:Nullable`1):Task

Daher habe ich vorerst die Nullfähigkeit von der Hub-Methode entfernt und 0 von der Client-Seite übergeben

Wiedereröffnung nach Ihren Erkenntnissen ...

Ich habe auch dieses Problem. Wird gelöst?

Klingt nach einer einfachen Sache, bei der der Ordner null in Nullable<T> konvertiert. Ich werde nachforschen.

Es stellt sich also heraus, dass dies tatsächlich beabsichtigt ist. Wie Sie tatsächlich ein Objektarray mit dem Wert null übergeben sollten. So am Beispiel
await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), new object[] {null}).ConfigureAwait(false);

Sie haben das vom Parameter-Resolver verwendete Parameter-Array auf Null gesetzt, anstatt einen Nullwert an ein Parameter-Array zu übergeben.

Soll das Problem in der aktuellen Version gelöst werden? Da das Ausgabedatum vor 5 Jahren lag, funktionieren optionale Parameter bei mir immer noch nicht?

@AlameerAshraf - zeigen Sie genau, was Sie versuchen zu tun. Ich glaube nicht, dass es derzeit Pläne gibt, etwas in diesem Bereich zu ändern.

Ich glaube nicht, dass optionale Parameter wie beabsichtigt funktionieren. Wir haben einen Aufruf ohne Parameter, dem ich einen Parameter hinzufügen möchte.

Leider gibt es keine Möglichkeit, dies zu tun, ohne die Abwärtskompatibilität zu beeinträchtigen, da unser Clientcode derzeit ohne Argumente aufruft. Ich erhalte System.IO.InvalidDataException: Invocation liefert 0 Argumente, aber das Ziel erwartet 1 - selbst mit einem einzelnen _nullable optionalen Parameter_.

Wenn ich meinen Client ändern muss, um eine Null zu übergeben, kann ich die Abwärtskompatibilität nicht aufrechterhalten und kann den optionalen Parameter auch überhaupt nicht verwenden 😦

Problemumgehung: Fügen Sie eine neue Methode mit einem anderen Namen hinzu und rufen Sie sie auf, die zur ursprünglichen Methode zurückgeleitet wird, wenn kein Parameter übergeben wird. Enttäuschend 👎

Ich denke wirklich, dass optionale Methodenparameter und Überladung unterstützt werden sollten - dies könnte tatsächlich überfällig sein, da es üblich ist, beide zu verwenden, und kontraintuitiv, sie bei Verwendung von SignalR nicht zu verwenden.

Hier im Jahr 2020 funktioniert das Überladen von Methoden, optionale Parameter jedoch nicht. Ich denke, es ist immer noch einfach, parametrisierte Methoden einfach von nicht parametrisiert aufzurufen und die Abwärtskompatibilität beizubehalten.