Add .ConfigureAwait(false) to await statements where possible

[rockfordlhotka]

This allows the specified task to run and return on pure background threads. Don't use this when the callback really does need to return to the UI (synchronized) thread, but otherwise this should be used to allow free-flowing tasks.

[rockfordlhotka]

This should only be done to code known to be server-side only. Any code that might run client-side must honor any existing synchronization context to avoid data binding issues, but pure server-side code (such as in the Csla.Server namespace) should be able to ignore any synchronization context.

[kellyethridge]

I think I may have hit this issue in my WebAPI application. I use the ObjectFactory approach to my CSLA architecture and everything is on the same server. For each user request I store a TimeProvider that uses time zone info stored in a web-token supplied in the request. It was stored in Application.ClientContext during an authentication process built in an Owin middleware. The TimeProvider has a static property ("Current") and sets and gets it from the ClientContext. When multiple requests came in, sometimes the wrong TimeProvider was used in the factory. I know this because the logged times were wrong. We logged a lot to ensure we tracked correctly. We also logged at the start of the request a well. In the originating thread, the times were always correct, but during the request the wrong time would sometimes be provided only when in the ObjectFactory. Digging into the CSLA source I found the ConfigureAwait(false) statements in the FactoryDataPortal and caller to the dataportal. Since the logical server-side code still requires the HttpContext used by Csla.Web's ClientContext, errors crept in. I then moved the storage of the TimeProvider to the User.Identity object as a property and have never seen the issue since. Unfortunately I cannot rely on ClientContext because of this. I'm wondering if a setting of some kind can be utilized for scenarios where HttpContext is used throughout the request. Or if there is an alternative you can suggest (maybe keep using User.Identity) I'm all ears.

Here is a StackOverflow Q&A which led me to this conclusion.

I may be completely wrong in my understanding of how the code is working. Please let me know if I'm way off here.

Thank You!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.