A minor issue I came across today. The client fails to make a call to a server method (error: Value cannot be null), if the server method accepts optional parameters and the client call excludes the optional parameter:
public void GetAll(long Id, bool DoSomething=false)
We can make method resolution smarter.
Definitely a good idea. Started actually working on that, but reverted to push the basic dynamic hubs implementation asap at that time.
Speaking of method resolving...
With current implementation we could also add method overloads support. Named parameter resolving would be possible to add too, but that would imply some modifications to how the parameters are actually passed between client and server (passing key-value pairs instead of just values). What'd you think?
Does this also apply for a Nullable parameter? I have a method with 3 parameters, the last of which is a nullable int (int?). If I set the last parameter to null I get the exception:
Value cannot be null.
Parameter name: o
at Newtonsoft.Json.Utilities.ValidationUtils.ArgumentNotNull(Object value, String parameterName)
at Newtonsoft.Json.Linq.JToken.FromObjectInternal(Object o, JsonSerializer jsonSerializer)
at Newtonsoft.Json.Linq.JToken.FromObject(Object o, JsonSerializer jsonSerializer)
Note that I have not set a default value for it on the server
We'll move this to the new repo as a v3 candidate