Just read a requirements document.
One of the requirements is that there should not be any async calls. It appears to be a security requirement.
Question is what are the security vulnerabilities of using async calls? Or any other reason to ban them?
All transport is over Https/SSL. The calls are web services between 2 systems.
There is nothing intrinsically wrong with asynchronous calls, although they can be harder to work with.
The only thing I can think of is that there might be a slight chance that the "completed" event could be spoofed and hence feed malicious data to your application.
However, I would have thought that the chances of that were remote.
Asynchronous calls can often have race conditions, which may, sometimes, lead to security vulnerabilities.
However, banning them outright for this reason is like banning the use of signed integers because they can sometimes lead to security vulnerabilities - the solution is understanding the problem, not sweeping it under the rug.
An asynchronous call, defined as one thread in a process spawning another thread to make the call and listen for the result while the parent thread continues on its business, is no more or less secure than the same call made synchronously. The only difference between the two, from the perspective of an outside observer of the process, is that a side thread is the one being blocked while waiting for the results of the call, instead of the main thread. The new thread gets a new stack and execution pointer, but shares the heap with all other threads of a process, and threads can access variables in other threads' stacks by reference. It's the same program, executing in the same memory space, it is just having its code executed from two places instead of one.
Further, it may be impossible to write a C# program that does not have any asynchronous operations; there are many such operations built into the runtime. Garbage collection, for instance, and threads used by the runtime to talk to various I/O layers. Event-driven UI programming is heavily threaded; the "main thread" of your program is called by the runtime's "UI thread" whenever the user does something; otherwise it's just waiting.
With asynchronous calls it is harder to keep proper context of the call as final portion of the call will be usually executed on random thread.Impersonation, thread local objects setup by runtime (like HttpContext.Current in ASP.Net), regular static/thread local objects need to be correctly restored before running code that may rely on them.
Not allowing asynchronous calls guarantees problems - non responsive UI in desktop applications and performance problems with services applications.
Also as everyone else pointed out writing asynchronous code is harder than synchronous. There are libraries that help writing such code - i.e. http://msdn.microsoft.com/en-us/magazine/cc546608.aspx
