You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current version of the SwaggerProvider only exposes synchronous network calls. It would be excellent if we had Async or Task-based versions as well, for throughput reasons.
I don't know which representation (Async or Task) would be best, especially because the operations from this library are often consumed by C# code.
Repro steps
Expected behavior
Asyncronous versions of the operations would be made available.
Actual behavior
Only synchronous versions of operations are present.
Known workarounds
You can manually manage Tasks/Asyncs of synchronous operations via the old-style BackgroundWorker/IAsyncResult mechanisms if you so wish.
Related information
The text was updated successfully, but these errors were encountered:
I would say asynchronous calls is a must, I would not expect any calls to be synchronous. In terms of Task/Async I would say support both, use a param on the TP to generate the non default one.
Description
The current version of the SwaggerProvider only exposes synchronous network calls. It would be excellent if we had Async or Task-based versions as well, for throughput reasons.
I don't know which representation (Async or Task) would be best, especially because the operations from this library are often consumed by C# code.
Repro steps
Expected behavior
Asyncronous versions of the operations would be made available.
Actual behavior
Only synchronous versions of operations are present.
Known workarounds
You can manually manage Tasks/Asyncs of synchronous operations via the old-style BackgroundWorker/IAsyncResult mechanisms if you so wish.
Related information
The text was updated successfully, but these errors were encountered: