Paneque's Technology Blog

Since we got the magic of async/await on C# things got much easier on the developer front. Working with Tasks is the key to it, but we also have two older approaches in .NET framework that we need to deal with.  APM (Asynchronous Programming Model) The pair of Being / End methods.  EAP (Event-based Asynchronous Programming) The Method Async / Method Completed pair. Converting from APM to Tasks is achieved by means of the   System.Threading.Tasks.TaskFactory   class and its generic counterpart. Now converting from EAP to Tasks  requires us to use the TaskCompletionSource<T> class and notify of the state of the task as it goes. See the example of a "handshake" operation in a WCF service. I am also using the approach from my older post regarding events and anonymous methods. The return type of the WCF operation is WrappedResultOfString , and that will be the actual generic parameter of the Task<T> that the HandshakeAsync method will produ...

Did you ever have a problem with a WCF client throwing exceptions you can't catch? If you have used WCF clients from Windows Phone, Silverlight or Xamarin.iOS, you might have noticed that it is not possible to create Synchronous or Task-Based operations; the functionality is reduced to the Event-based Asynchronous Pattern (EAP). That means that the way to call a WCF method and get the response is usually as follows: var client = new MyWCFClient(); client.DownloadDataCompleted += (sender, e) => { try { //accessing e.Result here might raise an exception in another //thread, that will not be captured by the 'catch' below. } catch(Exception ex) { } }; client.DownloadDataAsync(url); Our results are wrapped in an auto-generated class that inherits from  AsyncCompletedEventArgs , this class has a property  Error  of type  Exception , that will carry information about the error and a property  Result  with our expected return valu...

With Windows Communication Foundation it is easy to create any kind of services, of course my opinion could be biased because I am a .net (mainly c#) developer, but I really find hard to believe that someone could disagree with such statement. Of course there is a lot of know-how and trouble for beginners, specially trying to understand that WCF integrates all communication models we know (web, tcp, pipes, message queues) under one uniform paradigm. But there are some moments where you hit a rock in the path; years ago I stumbled upon the following scenario: I had a library “common.dll” that I used from both the client and the service. You might think this is not something you would do too often, and many people would say “that a client must not know anything about the service internals”. Well… that’s true, but this is not that case. It is just a situation where a client shares some business logic with the service. And the problem? Well, there is no problem with that config...