>If you're sending HTTP request synchronously I'd highly recommend you **don't** use HttpClient. Using the `.Result` property causes many issues and if you use it on a Web site you are very likely to lock up the application eventually when simultaneous requests are active hitting the same code.
>
>I'd recommend you just use WebClient() or HttpWebRequst() for synchronous HTTP requests, or if you want to use HttpClient() make sure you use Async/Await which requires that your calling method is async. Depending on what you call this code from this may be very easy to accomplish (like in an MVC controller you can just add `async` to the controller method and return a task (public async Task<ActionResul> MyMethod()).
>
>Whatever you do - stay away from using .Result with Async methods especially in Web applications - there are lots of issues there.
>
>+++ Rick ---

Rick,

Thanks a lot for the help. We need to call this from VFP (and also C# dll). In VFP the plan was to use function and return some parameters by reference. I found that I can not use await if the method uses ref parameters.

VFP dll is currently working as middleware - our C++ Sales application calls VFP.dll. Do your advice against Result still applies?


Changing my current code which I tested would be unfortunate as it took me a few days to just get it. But I guess I can use your recommendation and switch.

Also, I am having lots of troubles with the DotNetBridge. I tried the latest version, but I could not instantiate it.

And using the other version can instantiate the bridge but can not load my dll which is targetting version 4.5 of .NET. I tried to switch to .NET 4.0 but then I got too many errors.

Anyway, looks like I will have to change the whole thing again :(