Generic Extension Method for Dynamic Member Invocation - c#

I am trying to build a generic extension method that can call a member function of a class dynamically and return a specified type. For some background, this is the general problem:
I am using Autorest to generate some client libraries for a swagger API. Because some GET routes within the API return different objects depending on the HTTP status code of the response, the method invocation returns object and the developer is responsible for casting the object themselves. I am trying to create a convenient wrapper for doing this cast in a generic way.
Here is an example of a typical function signature that would be wrapped up:
object IPet GetPets(string petName)
Note that this method might return a number of object types, depending on the HTTP status code. For instance, 200 might return a Dog object but 404 might return a Cat object.
This would be invoked through an Autorest generated client library like this:
AnimalApi animalClient = new AnimalApi(new Uri("http://myanimals.com"));
object pet = animalClient.Pet.GetPets("dog");
if(pet is Dog) {
Console.WriteLine("Dog!");
} else {
Console.WriteLine("Not Dog");
}
I would like to scoop up this manual casting functionality into something a bit more intuitive, here is what I am thinking:
AnimalApi animalClient = new AnimalApi(new Uri("http://myanimals.com"));
string petType = "Dog";
Dog pet = animalClient.Pet.CallMethod<IPet, Dog, string>( (api,type) => api.GetPets(type), petType);
In this scenario, any return other than objects of type 'Dog' would cause an exception to be thrown. Here is my attempt at implementation:
public static Tout CallMethod<Tin, Tout>(this Tin client, Expression<Action<Tin, Targ>> apiCall, params object[] args)
where Tout : class {
MethodCallExpression providedMethod = apiCall.Body as MethodCallExpression;
if(providedMethod == null) {
throw new ApplicationException("Invalid method call provded");
}
var method = providedMethod.Method;
object responseData;
try {
// Call object-returning function
responseData = method.Invoke(client, args);
} catch(Exception error) {
if(error.InnerException is HttpOperationException) {
// Unknown error occurred
var ex = error.InnerException as HttpOperationException;
object content = JsonConvert.DeserializeObject(ex.Response.Content);
throw new ServiceException(ex.Response.StatusCode + ": "
+ JsonConvert.SerializeObject(content));
} else {
throw error.InnerException;
}
}
// Return formatted object if successful
if(responseData is Tout) {
return responseData as Tout;
// Otherwise throw
} else {
// Deal with known error object responses
if(responseData is ErrorResponse) {
var error = responseData as ErrorResponse;
throw new ServiceException(error);
} else {
// Unknown error occurred
throw new ServiceException("Unknown response was received: "
+ JsonConvert.SerializeObject(responseData));
}
}
}
The problem I have here is of passing the function and arguments into the generic extension method. Without knowing the various possible numbers of arguments that might be required by the various API calls, how can I define Expression<Action<Tin, Targ>> generically? It seems to me like I would have to replicate this function with Expression<Action<T1, T2, T3>> and so on to accommodate varying length argumen lists.
I want an expressive way for people to interact with the API, such that it is easy to see what is happening. However, this mechanism should be robust to various API changes down the road. My current goal is to provide a way to encapsulate common object casting and error checking operations. Is there a better way to do this? For the moment I am working under the assumption that the server side swagger doc cannot change.

Related

C# Templates and Unintended/Unexpected Inference

I am working with a bunch of legacy web services and trying to come up with a streamlined approach to wrapping calls and checking the custom error types that may be returned. I think I am close but C# infers a different meaning from what I intended and I am not sure what I am doing wrong. I am hoping someone can point out my mistake:
I have added a simple interface to the client proxy of each of the legacy services and created an extension method for calling methods and looking at the responses (each service has its own error types but all boil down to a number and a message).
public static ApiResult<TModel,TResult> Call<TService,TResult,TModel>(this TService service, Func<TService,TResult> apiCall, TModel model)
where TService: ILegacyService
where TModel: BaseModel
{
ApiResult<TModel, TResult> result = default(ApiResult<TModel, TResult>);
try
{
TResult apiResult = apiCall(service);
/* extract/normalize custom, non-exception error types */
result = new ApiResult<TModel, TResult>(model, apiResult, normalizedErrors);
}
catch(Exception ex)
{
result = new ApiResult<TModel, TResult>(model, default(TResult), exception: ex);
}
return result;
}
Where the ApiResult type is like:
public class ApiResult<TModel,TResult>
{
public ApiResult(TModel model, TResult response,
NormalizedErrorCollection errorList = null, Exception exception = null) { ... }
}
My hope is to then have a chain of checks for specific errors much like a series of catch blocks that can assign human-friendly messages to an error model in BaseModel, e.g.
serviceInstance.Call(s => s.SomeMethod("Foo", 42), modelInstance)
.On<ServiceCode>(ServiceCode.MaxQty, m => m.Message = "No more for you")
.On<ServiceCode>(ServiceCode.NoID, m => m.Message = "Parent is gone")
.On<Exception>((m,e) => m.Message = "Unexpected error")
.Success((m,r) => m.Result = r.Result)
My problem is right at the top which the helper method which infers a meaning I did not intend:
CartService.Call(s => s.AddToCart(request.storeId, lineItem), model);
C#/VS state that the < Method Response Type > cannot be used as type parameter TModel and that there is no conversion between < Method Response Type > and BaseModel.
I cannot seem to figure out why the return type from the apiCall TResult is inferred to be the model type. Any help would be greatly appreciated! (Finding specific answers to template questions is equally difficult so I apologize if this matches an existing answer, but I did try and search first).
The error information in the comments above indicate that AddToCartResponse is not derived from BaseModel.

How to invoke(not call directly) the Task<T>'s ContinueWith method?

For some business reasons, I cannot call the service's method directly, so I wrote the code like this:
class TheService {
public Task<string> CallMe(string input) {
return Task.Run(() => {
return "the result of " + input;
});
}
}
//The calling code segment...
//Get the target method's info
MethodInfo mi = typeof(TheService).GetMethod("CallMe");
//Get the target method's return type, yes, it's a Task<string>
ParameterInfo pi = mi.ReturnParameter;
Type taskType = pi.ParameterType;
//Get the service instance.(I new it here for simple reason)
TheService svc = new TheService();
//Invoke the target method and get the Task<string>, however I got only an object (not Task<string>) because I invoke it, not call it directly
object task = mi.Invoke(svc, new[] {"test"});
//How can I make a ContinueWith call here?
//This isn't work! It throws a conversion exception.
//Note: Task<string> is just an example. I wound actually get Task<MyClassA> or Task<MyClassB> here. So, I cannot hard code the conversion. However, I know the Type of Task<T> here. My instinct tells me I should use Invoke again but I don't know how to do.
((Task<object>)task).ContinueWith(a=>{
Console.WriteLine("The result is " + a.Result);
});
My question is how to call the object's (It's actually a Task) ContinueWith method?
Or anything workaround?
You can use the base class Task:
((Task)task).ContinueWith(a=>{
Console.WriteLine("The result is " + ((dynamic)a).Result);
});
Inside the completion callback ((dynamic)a).Result will be of type dynamic here. You can cast it or interrogate it using reflection. You can use reflection in the first place instead of dynamic if you like that better.
Another idea:
static void Run<T>(Task<T> task) {
...
}
Run((dynamic)task);
This uses dynamic to match the generic type arguments so that the call works.
It is because you cast Task<string> to Task<object>.
((Task<string>)task).ContinueWith(a => {
Console.WriteLine("The result is " + a.Result);
});
Remember that types with different generic constraint are not interchangeable.
If situation is trick that the task return type is unknown, you can keep using reflection.
((Task)task).ContinueWith(t =>
{
var resultProperty = t.GetType().GetProperty("Result");
var resultObject = resultProperty.GetValue(t);
Console.WriteLine("The result is " + resultObject);
});

Best way to debug yield return that is consumed during serialization?

I'm working on an application that embeds JSON within the page. Some simplified example:
public ViewResult Page(IEnumerable<LolCat> lolCats)
{
var json = new
{
localCats = ToJson(lolCats),
};
return View( json ); // this gets serialized somewhere in the ASP pipeline
}
IEnumerable<object> ToJson(IEnumerable<LolCat> lolCats)
{
foreach ( var lolCat in lolCats )
yield return new { name = lolCat.name };
}
The JSON gets automatically serialized somewhere down the line in the ASP.NET pipeline.
In this example assume that sometimes a NULL slips into lolCats, throwing an exception. Problem is that the ToJson function might be called at a lot of different places throughout the application.
How do I find out which call to ToJson was the one responsible for the exception? The call stack ends in the Serializer that is actually consuming this IEnumerable, and therefore you don't see the 'original stacktrace'.
One simple fix would be to call ToList() within Page. But I'm looking for a way that doesn't break the laziness of the method.
Due to the deferred nature, you will never get which call to ToJson() actually produced the exception. The collection was never inspected in the first place until it was first enumerated (when it was serialized).
You need to inject into your enumerator some info about what called it.
e.g.,
IEnumerable<object> ToJson(IEnumerable<LolCat> lolCats, string id)
{
try
{
foreach (var lolCat in lolCats)
yield return new { name = lolCat.name };
}
catch (Exception ex)
{
throw new Exception(id, ex); // use a more appropriate exception
}
}
Then it's just a matter of generating an id that could help identify the caller.

RestSharp unable to cast object when awaiting for response

Using RestSharp I'm building an API to perform CRUD operations given a datatype/object.
My CrudAbstract class is generic and has the following:
public virtual async Task<keyType> Post(dto item)
{
try
{
var request = await _client.GetRequestAsync(_path);
request.Method = RestSharp.Method.POST;
request.AddJsonBody(item);
var result = await _client.ExecuteRequestAsync<keyType>(request);
return result;
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
throw new Exception("Was not able to process crud post operation.");
}
My WebClient class has the following:
Entities = new CrudAbstract<DtoEntity, int>("/entities", this); // in constructor
// So the keyType from definition above is int (Int32)
The post method in this class is
public async Task<T> ExecuteRequestAsync<T>(IRestRequest request)
{
try
{
var response = await GetClient().ExecuteTaskAsync<T>(request);
// Exception occurs here. The above statement is unable to finish.
var data = response.Data;
return data;
}
catch (Exception e)
{
// Log exception
}
throw new Exception("Was not able to process restclient execute async method.");
}
My Api EntitiesController has the following:
public int Post(DtoEntity value)
{
using (var db = // some database...)
{
try
{
// Upsert object into database here
//... value.Id no longer null at this point
/*
The problem occurs here. I only want to return the ID of the object
(value.Id). I do not want to return the whole object (value)
*/
return value.Id;
}
catch (Exception e)
{
// Log exception
}
}
throw new Exception("Was not able to process entities post method.");
}
The exception I get is:
Unable to cast object of type 'System.Int64' to type
'System.Collections.Generic.IDictionary`2[System.String,System.Object]'.
This is basically saying it is unable to cast the object int (which I have returned in the post with value.Id) to a DtoEntity object (which is the actual object on which CRUD operations were performed).
What am I doing wrong?
I have placed typeof and .getType() onto each keyType, T, and value.Id, and all of them are Int32. Is it in the RestSharp library that the problem occurs? At what stage is there a casting of int to a DtoEntity in the line:
var response = await GetClient().ExecuteTaskAsync<T>(request);
Note: when I change the return type of the post method in my controller to DtoEntity and change the value.Id to just value it works. The response is received, and the response.Data is the DtoEntity object.
I've seen similar questions here but not found a solution yet.
I believe you've spotted a bug in RestSharp. RestSharp internally uses a JSON parser called SimpleJson (borrowed from the Facebook .NET SDK). It appears that this parser is correctly deserializing the response body to a number (since JSON is untyped it uses Int64 to be safe), but the RestSharp's JsonDeserializer class attempts to cast this result to an IDictionary in the first line of this method:
private object FindRoot(string content)
{
var data = (IDictionary<string, object>)SimpleJson.DeserializeObject(content);
if (RootElement.HasValue() && data.ContainsKey(RootElement))
{
return data[RootElement];
}
return data;
}
I think your options are:
File an issue with the RestSharp team.
Get the raw string body and cast it to an int yourself (may be the path of least resistance).
Try a different library.

C# Generics and using the non-generic version from typed method

I'm using the RestSharp library to access a REST API.
I want all the API requests to go through the same method, so I can add headers, handle errors and do other stuff in a central place.
So I made a method that accepts a generic Func<> and that solves most of my problems, but I don't know how to handle the case where I don't have a return type.
private T PerformApiCall<T>(RestRequest restRequest, Func<RestRequest, IRestResponse<T>> restMethod)
{
var response = restMethod.Invoke(restRequest);
//handle errors
....
return response.Data;
}
I call it like this:
var apples = PerformApiCall(new RestRequest('/api/apples'), req => Client.Execute<List<Apple>>(req));
But I came across a problem, a bunch of API calls don't have a return type because they don't return data. So I used Client.Execute(req) and I get the error saying the type arguments cannot be inferred, I tried to pass , but that failed because it couldn't convert the non-generic IRestResponse to the typed one.
Any ideas on how to tackle this in a nice way?
One thing you could try is to add an overload to your PerformApiCall function that takes a Func with a non-generic result type, and returns nothing:
// Notice the `Func` has `IRestResponse`, not `IRestResponse<T>`
public void PerformApiCall(RestRequest restRequest,
Func<RestRequest, IRestResponse> restMethod)
...
Then, depending on how complex your error checking/logic is, you could move it out to a separate method (which returns the response), and call it from both overloads of PerformApiCall:
private T PerformRequestWithChecks<T>(RestRequest restRequest,
Func<RestRequest, T> restMethod)
where T : IRestResponse
{
var response = restMethod.Invoke(restRequest);
// Handle errors...
return response;
}
// You can use it from both versions of `PerformApiCall` like so:
//
// // From non-generic version
// var response =
// PerformRequestWithChecks<IRestResponse>(restRequest, restMethod);
//
// // From generic version
// var response =
// PerformRequestWithChecks<IRestResponse<T>>(restRequest, restMethod);
// return response.Data;
You were getting a compiler error because it is sound to treat a subtype as if it was an instance of its supertype, but it is not sound to do it in the other direction (which is what was happening when you changed your calling code to just Client.Execute(req), returning a non-generic).
Here's an ideone paste illustrating this: http://ideone.com/T2mQfl

Categories

Resources