This is asynchronous operation! You should not assume that the result is ready immediately. For a while
response.Result
will remain null, and later it might turn to real result.
So, the conclusion is: in both cases, in your console-only application and WCF application, this fragment of code was wrong, really badly wrong. The fact it ran in console application is even worse: it looks like the only difference is
timing. You created a bad thing,
incorrect dependency on the order of execution, usually called
race condition:
http://en.wikipedia.org/wiki/Race_condition[
^].
The readiness of the result of asynchronous operation and check up of this result raced again each other; if the result was ready sooner, it created only the
illusion of success.
For asynchronous operation usage, please see:
http://msdn.microsoft.com/en-us/library/system.net.http.httpclient.postasync%28v=vs.118%29.aspx[
^],
you used this form of it:
http://msdn.microsoft.com/en-us/library/hh138190%28v=vs.118%29.aspx[
^].
For
correct use of asynchronous result, please see, for example, this code sample:
http://www.asp.net/web-api/overview/web-api-clients/calling-a-web-api-from-a-net-client[
^].
Now, for service operation (and many other cases), I usually recommend using synchronous (blocking) API in combination with explicitly created separate threads. Please see my arguments:
problem in multithreading ? !!![
^],
TcpListener, TcpClient, Ping in Visual Basic 2005[
^],
TCP Socket - Send and receive question[
^],
Async Await Multiple Telnet Servers[
^].
—SA