Signalr: Parámetros opcionales

Podemos hacer que la resolución de métodos sea más inteligente.

Definitivamente una buena idea. Comencé a trabajar en eso, pero volvió a impulsar la implementación de los centros dinámicos básicos lo antes posible en ese momento.

Hablando de método de resolución ...
Con la implementación actual, también podríamos agregar soporte para sobrecargas de métodos. También sería posible agregar la resolución de parámetros con nombre, pero eso implicaría algunas modificaciones en la forma en que los parámetros se pasan realmente entre el cliente y el servidor (pasando pares clave-valor en lugar de solo valores). ¿Qué te parece?

¿Esto también se aplica a un parámetro que acepta valores NULL? Tengo un método con 3 parámetros, el último de los cuales es un int que acepta valores NULL (int?). Si configuro el último parámetro en nulo, obtengo la excepción:

El valor no puede ser nulo.
Nombre del parámetro: o

en Newtonsoft.Json.Utilities.ValidationUtils.ArgumentNotNull (Valor de objeto, String parameterName)
en Newtonsoft.Json.Linq.JToken.FromObjectInternal (Object o, JsonSerializer jsonSerializer)
en Newtonsoft.Json.Linq.JToken.FromObject (Object o, JsonSerializer jsonSerializer)
en Microsoft.AspNet.SignalR.Client.Hubs.HubProxy.Invoke T
en GeoTag.App.Core.Services.SignalRClientService.d__9.MoveNext ()

Tenga en cuenta que no he establecido un valor predeterminado para él en el servidor

Lo trasladaremos al nuevo repositorio como candidato v3

@JasonBSteele : sé que ha pasado un tiempo, pero el problema que mencionas se solucionó. Espere verlo en la próxima versión.

Estoy confundido en cuanto al estado de este problema. ¿Se ha solucionado en alguna versión de SignalR?

@paulirwin No

...

La solución está en 2.2.1 que se envió en julio (https://github.com/SignalR/SignalR/releases/tag/2.2.1)

Volví a probar lo que encontré ayer, aquí están mis hallazgos:
Método de concentrador al que llamará el cliente

public async Task EpicMethod( int? daysTillNETStandard20 ) {}

Intentos de invocación del método de servidor cliente .NET:

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

así que por ahora eliminé la nulabilidad del método del concentrador y pasé 0 desde el lado del cliente

Reapertura según su hallazgo ...

Tengo este problema también. ¿Se resolverá?

Suena como una simple cuestión de que el aglutinante no convierte null en Nullable<T> . Yo investigaré.

Entonces resulta que esto es en realidad por diseño. Cómo debería pasar una matriz de objetos con el valor de nulo. Así usando tu ejemplo
await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), new object[] {null}).ConfigureAwait(false);

Lo que estaba haciendo era configurar la matriz params que el resolutor de parámetros estaba usando en null en lugar de pasar un valor nulo a una matriz params.

¿Se supone que el problema está resuelto en la versión actual? Dado que la fecha de emisión fue hace 5 años, ¿pero los parámetros opcionales aún no me funcionan?

@AlameerAshraf : muestra exactamente lo que estás intentando hacer. No creo que haya planes para cambiar nada en esta área en este momento.

No creo que los parámetros opcionales estén funcionando como se esperaba. Tenemos una llamada sin parámetros, a la que estoy buscando agregar un parámetro.

Desafortunadamente, no hay forma de hacer esto sin romper la compatibilidad con versiones anteriores, porque nuestro código de cliente actualmente llama sin argumentos, obtengo System.IO.InvalidDataException: Invocation proporciona 0 argumento (s) pero el objetivo espera 1, incluso con un solo _ parámetro opcional anulable_.

Si tengo que cambiar mi cliente para pasar un nulo, entonces no puedo mantener la compatibilidad con versiones anteriores y es posible que no use el parámetro opcional en absoluto 😦

Solución alternativa: agregue y llame a un nuevo método con un nombre diferente, que se reenvía al original si no se pasa ningún parámetro. Decepcionante 👎

Realmente creo que los parámetros de métodos opcionales y la sobrecarga deberían ser compatibles; esto podría estar retrasado en realidad, ya que es común usar ambos y no es intuitivo no usarlos cuando se usa SignalR.

Aquí, en 2020, la sobrecarga de métodos funciona, pero los parámetros opcionales no; de todos modos, creo que aún es fácil llamar al método parametrizado desde no parametrizado y manteniendo la compatibilidad con versiones anteriores.