I'm aware of the problem that TransactionScopeAsyncFlowOption.Enabled solves:
- https://particular.net/blog/transactionscope-and-async-await-be-one-with-the-flow
- How to support async methods in a TransactionScope with Microsoft.Bcl.Async in .NET 4.0?
- https://stackoverflow.com/a/17527759/1662268
And I'm aware (per the first link above) that Microsoft didn't just fix the bug in the default behaviour because Backwards-Compatibility Is King.
But as far as I'm aware, the only change here is that "something that used to throw an Exception, to indicate that it couldn't do what you'd asked it to do, now works."
i.e. the only change is that some code that used to die horribly, now JustWorks(TM), in exactly the way that you would have expected it to if you'd never heard of this bug.
So, the only way I can imagine that it could break an existing codebase is if that codebase had some code that did the bad flow, and then actively expected the InvalidOperationException("A TransactionScope must be disposed on the same thread that it was created."), caught it, and did something specific as a result. (Or if the codebase relied on a certain invocation path being broken?
Either of which would be ... a little odd.
=-=-=-=-=-=-=-=-=-=-=
Supposing I'm confident that my codebase doesn't have anything that explicitly looks for these Exceptions and behaves differently if they occur, and was otherwise broadly sane ... Is there any reason NOT to just enable TransactionScopeAsyncFlowOption everywhere?
Does enabling this option have any side-effects other than "making this use-case JustWork"?
