Develop Reference

Ambiguous routing exception in gRPC .NET 5 / C# project

I've created my 1st gRPC App in .NET5, using Grpc.AspNetCore and protobuf-net nugets.
Initially all my service methods were synchronous. At this stage client-server communication functioned well.
Then I found that I need async support too, and added an async equivalent for each existing method, like:
AssemblyNamesDto GetAssemblyNamesFromFiles(MyDto payload);
Task<AssemblyNamesDto> GetAssemblyNamesFromFilesAsync(MyDto payload);
Since I've done this I get Exceptions on the server side with the message:
Microsoft.AspNetCore.Routing.Matching.AmbiguousMatchException: The request matched multiple endpoints.
If I rename the Async "overload" to something like GetAssemblyNamesFromFiles2Async, the AmbiguousMatchException goes away.
So my assumption is that there is generated code somewhere that makes pairs of synchronous and asynchronous method names implicitly.
Adding "Async" at the the end of the synchronous method name and vice versa.
I've seen this in WCF-REST projects that method pairs like this are are generated automatically.
So my question is: if the async methods are generated automatically, how can I use them?
I can't find generated code files in the project.
Or: how can I somehow solve the routing ambiguity issue by e.g. adding [Route] attributes or by other means?
I used the gRPC project template of VS 2019.
I didn't add any routing attributes. The service just implements the service interface methods, which have no overloads with same name.
The project is not ASP.NET MVC.

Calling a WCF service without generating an Assembly

I am trying to write some code in C# that will call a WCF service on the fly by importing the WSDL, examining it and then making calls to it dynamically.
The service I am calling can change from time to time - so if it does I want my client to know about new methods and new input parameters and output parameters to the calls, without rebuilding my client.
One possible solution to this is to import and compile a service reference on the fly.
Outlined here: Creating an assembly on the fly from a WSDL
I would like to avoid the generation of an assembly and then reflecting over it if possible.
I looked into the code of the dynamic proxy in the link and they use a framework class to do the import. This class is the WsdlImporter. So I had thought great - I can use that and examine the WSDL schema and determine what calls are present and what inputs and outputs are available.
The problem is that the type information is missing in the MessagePartDescription objects that the WsdlImporter creates. Apparently this is missing because it cannot find the types yet - see the response to the question from Brian.
So any advice on how I should proceed? Am I completely on the wrong track here?

This is probably not an answer but I will post it as one to fully describe my opinion.
Dynamic proxy:
IMO this is example of wrong usage of technology. It is elementary behavior of WSDL - if it changes you have to change client or you have to make good WSDL versioning and create new client.
You still have to somehow say your client to get WSDL - does it mean that you will parse WSDL before each call? Doesn't seem like a good idea.
Information about types is really not part of WSDL because by default WSDL is generated as interoperable. CLR types are not operation needed for interoperability. When you create service proxy by Add service reference or Svcutil it will generate code for types defined in WSDL. That code then need to be compiled.
You can try to use NetDataContractSerializer instead of default DataContractSerializer. NetDataContractSerializer adds CLR type information into WSDL but I still expect that new types must be known to your clients - it means deploying new assembly with types and use it by clients. This almost sounds like same approach when simply deploying assembly with new static client proxy.
Dynamic WF client
I also don't see too much usage of this architecture - you still need to change client to reflect new WF steps, don't you?
Changing the WF
Are we talking about Windows Workflow foundation? I can hardly imagine scenario where you create WF, expose it as a service and then change it. When you expose WF as service you are probably defining long running WF. Long running WFs use persistance which is based on serialization (at least in WF 3.5 but I believe it is same in WF 4). When you change WF definition, all persisted WFs are most probably doomed because they will never ever deserialize. This situation is usually solved by parallel deployment of new and old version where old version is only used to finish incomplete WFs. Again it means new clients.

If you look at the problem from a different angle. Do you need to regenerate the proxy each time or do you need a contract that continues to work when things change?
WCF has a mechanism for this IExtensibleDataContracts see: http://msdn.microsoft.com/en-us/library/ms731083%28v=VS.100%29.aspx
Best practices for versioning of contracts can be found here

how to perform pre processing the method call details before the method is executed in C#

HI all,
I am not sure whether this is possible in C# or in any other language for that matter. Below is my requirement
It is a service application which will get some commands to execute. Those commands are predefined (methods in classes). When user calls these methods, the application framework must call another method (a default method) and complete the execution then execute teh called method. I understand there is a possibility of performance but i am in need of this type of architecture.
To explain better below is an example
Step 1: User A calls a webservice method GetData (string dataid, string dataLocation).
step 2: webservice recieves this call as http get method and it must first execute a default method CheckData(GetData).
Step 3: CheckData will now check the data which was sent to GetData Method and then it executes the GetData Method.
This way i can perform some operations like authentication, cleanup works and also other various system activities. Will it be possible for this kind of model.
My requirement is
User calls Webservice method employee.GetQualification.
In webservices, the call stack must be
Validater.CheckData (GetQualification)
Employee.GetQualification()
Validator.CheckOutput(output)
I am not looking for something like below (method stack)
Employee.GetQualification()
Validater.CheckData (getQualification parameters)
execute actual execution
Validator.CheckOutput(output)
Return
Some links/ thoughts would be beneficial for me to start on
Thanks.

Sounds like you are looking for a weaver like PostSharp (unfortunately not free any more).
Edit: Just remembered another aspect-oriented programming (AOP) library: LOOM.NET.

At the method level, there is no way to do exactly what you want, but if you're using WCF, you can create a custom behavior that does this for you.
See this article for examples, particularly the bit about IParameterInspector.
Personally, I don't think I would use this approach though, unless you need it to be configurable behavior. Hard coding a call to a single private method to do some validation at the start of some operation isn't so bad.

This seems to be a typical scenario for an AOP framework, e.g. have a look at the logging sample in the PostSharp tutorial
In web apps or in a WCF environment, there are certainly other approaches (e.g. HttModules), but by an AOP-based approach will work in any environment.
Note: there is a free community edition of PostSharp and the older version 1.5 is also free. And of course there are other AOP frameworks, such as Spring.NET.

You could write a sink for yourself which hooks in before and after your method executes. I had written a sink sometime back, check it out : http://technologyandme.blogspot.com/2009/05/putting-c-attributes-to-use.html

C# Cannot call <function> because it is a web method

I have a custom C# component library (D1) that has a web reference, D1 is referenced by in library (D2) that makes call to methods in the web reference. D2 is loaded into a console application using reflection.
When I reference D1 above, in a test console application and make calls to the methods in the web reference. However, when I load it using reflection and make those same calls, receive the the following error: cannot call because it is a web method"
I have tried this using the .NET 2.0 and 3.0 framework.
Any thoughts?

I got the same error when I was checking value in the debugger. I'm not sure how comparable that is to your reflection call.
My code called it just fine but the debugger threw this error.
Hopefully that may help someone

It would be good practice for the class exposing the [WebMethod] tagged API to be a thin shim over the real implementation -- it is possible that the calls you see working are bypassing such a shim.
What does Reflector have to say about the assembly?

ASP.NET Web Service Results, Proxy Classes and Type Conversion

I'm still new to the ASP.NET world, so I could be way off base here, but so far this is to the best of my (limited) knowledge!
Let's say I have a standard business object "Contact" in the Business namespace. I write a Web Service to retrieve a Contact's info from a database and return it. I then write a client application to request said details.
Now, I also then create a utility method that takes a "Contact" and does some magic with it, like Utils.BuyContactNewHat() say. Which of course takes the Contact of type Business.Contact.
I then go back to my client application and want to utilise the BuyContactNewHat method, so I add a reference to my Utils namespace and there it is. However, a problem arises with:
Contact c = MyWebService.GetContact("Rob);
Utils.BuyContactNewHat(c); // << Error Here
Since the return type of GetContact is of MyWebService.Contact and not Business.Contact as expected. I understand why this is because when accessing a web service, you are actually programming against the proxy class generated by the WSDL.
So, is there an "easier" way to deal with this type of mismatch? I was considering perhaps trying to create a generic converter class that uses reflection to ensure two objects have the same structure than simply transferring the values across from one to the other.

You are on the right track. To get the data from the proxy object back into one of your own objects, you have to do left-hand-right-hand code. i.e. copy property values. I'll bet you that there is already a generic method out there that uses reflection.
Some people will use something other than a web service (.net remoting) if they just want to get a business object across the wire. Or they'll use binary serialization. I'm guessing you are using the web service for a reason, so you'll have to do property copying.

You don't actually have to use the generated class that the WSDL gives you. If you take a look at the code that it generates, it's just making calls into some .NET framework classes to submit SOAP requests. In the past I have copied that code into a normal .cs file and edited it. Although I haven't tried this specifically, I see no reason why you couldn't drop the proxy class definition and use the original class to receive the results of the SOAP call. It must already be doing reflection under the hood, it seems a shame to do it twice.

I would recommend that you look at writing a Schema Importer Extension, which you can use to control proxy code generation. This approach can be used to (gracefully) resolve your problem without kludges (such as copying around objects from one namespace to another, or modifying the proxy generated reference.cs class only to have it replaced the next time you update the web reference).
Here's a (very) good tutorial on the subject:
http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wsproxy.mspx