Any disadvantage of using ExecuteReaderAsync from C# AsyncCTP

I disagree with Ricka on this. Async DB commands are not only good, they are critical in achieving scale, throughput and latency. His objection about the ramp up time of the thread pool applies only to a web server that experiences low traffic volumes.

In a high traffic situation (which is the only one that matters), the thread pool won't have to wait for 'injecting' new threads. Doing the SQL Commands asynchronously is important not only from the point of view of web server requests/threads health, but also from the point of view of total request lifetime/latency: uncorrelated DB calls can be done in parallel, as opposed to sequentially. This alone results usually in dramatic improvements in the latency of the HTTP request as experienced by the user. In other words, your pages load faster.

A word of advice though: SQL Command is not truly asynchronous until you enable Asynchronous Processing=true on the connection string. While this is not set (and by default is not, Edit: starting with .NET Framework < 4.5. Asynchronous Processing is no longer required) your 'asyncronous' calls to BeginExecuteReader are nothing but a sham, the call will launch a thread and block that thread. When true async processing is enabled in the connection string then the call is truly async and the callback is based on IO completion.

A word of caution: an async SQL command is completing as soon as the first result returns to the client, and info messages count as result.

create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCountasbeginprint 'Hello';select complex query;end

You've lost all benefits of async. The print creates a result that is sent back to the client, which completes the async command and execution on the client resumes and continues with the 'reader.Read()'. Now that will block until the complex query start producing results. You ask 'who puts print in the procedure?' but the print may be disguised in something else, perhaps something as innocent looking as an INSERT that executes without first issuing a SET NOCOUNT ON.

I notice that the following question wasn't answered:

So, is there any disadvantages of using this new async programming model here?

The disadvantage which is very minimal (minor cpu/minor memory afaik), is that because there is the possibility of any code running after an await statement may run on a separate thread, a state-machine exists to store the state of the currently running thread so that the continuation of work can be handled on another thread. You can read more about the await/async statemachine on Dixin's Blog - Understanding C# async / await (1) Compilation.