D
dbeavon
Guest
Are you doing this from a U/I environment or from a PASOE agent? That makes a ton of difference where async operations are concerned. I will assume you are running this in _mproapsv (PASOE). Generally speaking you can change an async api into a synchronous one by using Task.Run() to send a task to the TaskScheduler (thread pool). Once you've sent it, you immediately wait on it (using the GetAwaiter().GetResult()). You may find cautionary tales about doing stuff like this, but they are typically related to environments where there is a U/I, a dispatcher, you are performing U/I -related in your Task, and there is a potential for U/I related deadlocks in the dispatcher (eg. winforms or wpf). Async programming is a half-way point between synchronous and multi-threaded development. In most cases it just works. Have you tried just forgoing the "await" and assigning the task to a local (TaskObj) and then using TaskObj.GetAwaiter().GetResult(). I would suspect that will work. It would depend on something called the ambient "synchronization context". Caveat: I would assume that the CLR bridge in _mproapsv has a normal TaskScheduler (the thread pool). But I haven't tried this for myself. If I were you, I'd take a drastically different approach and create a local windows service to host a WCF interface (SOAP or REST) and interact with that stuff rather than trying to do this "in-process" - within an ABL host process like _progres or _mproapsv. ... The CLR bridge is nice in a pinch but has limitations. If you are trying to build something complex (more than 100 lines of .Net interop) then it may be better to switch to an out-of-process approach.
Continue reading...
Continue reading...