This project is read-only.

No async invocations!

Nov 6, 2013 at 2:07 PM
Asynchronous Invocations
I can't find BeginCallService method in whole source! This is not implemented!
Nov 7, 2013 at 1:48 PM
The asynchronous methods should be defined in the service contract that you're using.
When adding a service reference, you can turn on the option of generating asynchronous operations. There are several kinds (Task-based, APM-Begin/End, and Event-based).
If you're not adding a reference through meta-data, and you simply copy the contract from the service side, you can always add the operations yourself.

Once you have the asynchronous operations within the contract, it would simply be part of the 'Channel' property, then you can call it and use it as the example describes.

One more thing, I believe the showcases have such a sample, just download it and grab a look.

If you're working with Task-based operations (.NET 4.5), then unfortunately it is currently unsupported, but the good news is that there's already a newer version implemented which does support it, I just didn't get to post it yet.
Nov 14, 2013 at 7:39 AM
I understand now what you mean in wiki. I know about different kinds of generated proxies. Why did you write about async invocations in wiki if this lib has nothing to help with it? No useful functionality. I've meant something like Castle WCF Facility async calls. But I need it without castle dynamic proxy and simpler. I've just implemented it myself with building nested async-interface (inherits sync version) at runtime and using expression trees to convert sync-method call to async with callback. No IOC/dynamic proxy was involved/required.
Nov 14, 2013 at 7:55 AM
It is true that WCF Contrib doesn't currently provide something in that regards, but it does help a tiny bit about the entire APM (Begin/End) sequence.
Normally, you would have to call the 'BeginXXX' operation and supply a callback in which you should call the 'EndXXX' operation and inspect the result or exception. Needless to say, the 'BeginXXX' operation can too throw exceptions so you need to catch those too.

WCF Contrib simplifies the usage of this pattern by managing the calls to the 'Begin' and 'End' on the proxy internally.
This means that you can now call the 'Begin' operation on the ClientChannel.Channel and supply a callback to get the following simplified behavior:

1) Begin shouldn't throw exceptions unless there's custom code that might fail of course
2) In the callback, you can cast the IAsyncResult you receive as a parameter to 'ChannelInvokeAsyncResult' to inspect the error or the result. This is the actual end result.
3) You don't need to call the End operation, it is done for you internally
4) You don't need two catch statements (begin / end)

Anyway, the feature you were referring to does sound pretty cool and I'm glad to hear you got to a suitable solution.
A dynamic proxy could help if you wanted to provide an API for exposing synchronous operations as asynchronous without having the developer actually write these asynchronous service contracts.