It's not svcutil magic, it's built into WCF - the channel factory on the
client creates an implementation of the service interface that supports
both synchronous and asynchronous calls:
https://marcinjuraszek.com/2018/01/async-wcf-with-channelfactory.html
Judicious mapping of the ServiceContract/OperationContract names in the
service interface can let you call the method you want.
The poor maintenance person later on might say that Add Service
Reference/svcutil is the kinder option for generating the proxies
though. :-)
T
On 22/05/2020 16:23, Greg Keogh wrote:
TGIF again,
The svcutil command is doing something magical when it generates WCF
client code. The generated interface and class have both synchronous
and async methods for each service method. And it doesn't matter if
your original service methods are async or not, you still get pairs
generated either way. If I have a service with a non-async method
GetData() and I run it through svcutil I get a class like this (trimmed):
public class MyServiceClient : ServiceClient<IMyService>
{
public Task<string> GetDataASync();
{
return base.Channel.GetDataAsync();
}
}
Getting async methods is fabulous, but where on earth do they come and
how do they work? I spied into the IL to see what's happening, but all
generated methods call into a generic TChannel (transparent proxy)
which contains no recognisable code. Is it dynamic code generation?
But it gets worse...
Svcutil generates vast overkill code, so I prefer to make my own
client by manually coding a class with the exact same signature as the
generated one above. This works, but /all the async methods are
missing/. What the hell is the difference between the svcutil
generated code and mine? Where did the async methods come from, and
where did they go?
/Greg K/
