This change implements the first step towards Roslyn working in applications using vs-threading with reduced risk of concurrency bugs. Recommend reviewing by commit after looking at the full list to get an idea for the overall direction.

Most of the work in this change involves internal propagation of the IThreadingContext instance, which provides access to the JoinableTaskFactory used in Roslyn code.

Following this pull request, several diagnostics remain disabled.

• VSTHRD002 (Avoid problematic synchronous waits): Many of the violations reported by this can be fixed by a code fix, but the code fix is a bit buggy and I'm waiting for Preserve assertion when fixing VSTHRD103 microsoft/vs-threading#338 so it's easier to prepare the fixes.
• VSTHRD103 (Call async methods when in an async method): This will be sent as a follow-up pull request. The analysis will be improved by Treat 'Synchronously' as a suffix for synchronous methods microsoft/vs-threading#331, but I didn't see any reason why it would block our use of the analyzer.
• VSTHRD110 (Observe result of async calls): We need to establish the "Roslyn desired practice for FileAndForget" before enabling this diagnostic.
• VSTHRD200 (Use "Async" suffix for async methods): Will send a follow-up PR to enable this and fix all cases that aren't exposed (public API and/or IVT). It affected too many files to include here.
• VSTHRD010 (Invoke single-threaded types on Main thread): This diagnostic is enabled, but its accuracy relies heavily on configuration files provided separately. The configuration for VSSDK types ships with the VSSDK analyzers, which are not yet enabled for the full Roslyn build.

Known follow-up issues (GitHub issues will be linked here once they are available):

• Enable VSTHRD002 (see above)
• Enable VSTHRD103 (see above)
• Enable VSTHRD110 (see above)
• Enable VSTHRD200 (see above)
• Configure WaitAndGetResult and WaitAndGetResult_CanCallOnBackground as problematic synchronous waits (blocked on Allow extensions for VSTHRD002 (Avoid problematic synchronous waits) microsoft/vs-threading#344)
• Review code for additional methods to consider legacy thread switching APIs (blocked on Allow extensions for VSTHRD001 (Avoid legacy thread switching APIs) microsoft/vs-threading#332)
• Update VSSDK analyzers to enable VSTHRD010 (see above)
• Eliminate ForegroundThreadDataKind, and gut or eliminate ForegroundThreadAffinitizedObject Migrate to Microsoft.VisualStudio.Threading #28781 (comment)
• Consider making JoinableTaskContext a required import for ThreadingContext Migrate to Microsoft.VisualStudio.Threading #28781 (comment)
• Eliminate JoinableTaskFactoryTaskScheduler, or at least add it to the set of legacy thread switching types Migrate to Microsoft.VisualStudio.Threading #28781 (comment)
• PERF: Improve CPSProject_IWorkspaceProjectContext.cs Migrate to Microsoft.VisualStudio.Threading #28781 (comment)
• Design, implement, and uniformly use a main thread check/assert method Migrate to Microsoft.VisualStudio.Threading #28781 (comment)
• PERF: Remove AbstractPackage.ForegroundObject, and its costly initialization Migrate to Microsoft.VisualStudio.Threading #28781 (comment)
• Test devenv /build Migrate to Microsoft.VisualStudio.Threading #28781 (comment)
• Audit uses of ContinueWith, SafeContinueWith, StartNew, SafeStartNew, and Task.Run to identify cases where simpler approaches are viable Migrate to Microsoft.VisualStudio.Threading #28781 (comment)
• Inconsistent use of TestWorkspace.GetService<T> and TestWorkspace.ExportProvider.GetExportedValue<T> Migrate to Microsoft.VisualStudio.Threading #28781 (comment)

Customer scenario

This is an internal code change that allows dotnet/roslyn to be more easily incorporated into applications that involve user interfaces and leverage the Microsoft.VisualStudio.Threading library for deadlock and reentrancy mitigation and overall best practices.

Bugs this fixes

N/A

Workarounds, if any

Fixing bugs as they occur.

Risk

This change has moderate risk, but I believe it's relatively low risk considering its scope since existing behaviors were preserved where possible. The primary points where I see risk are the following:

• Not all portions of code were updated to follow the Three threading rules, and incremental adoption of vs-threading runs a risk of deadlocks when code does not follow these rules.
• While the documented precondition of WaitAndGetResult was weakened, the debug assertion it contained was strengthened substantially. This code does not affect release builds, but despite the work in this pull request it may continue to affect debug pull request builds.

Performance impact

Performance should not change substantially as a direct result of this pull request. Over time, performance should improve by allowing more code to use asynchronous operations and more efficient task continuations.

Is this a regression from a previous update?

N/A

Root cause analysis

N/A

How was the bug found?

N/A

Test documentation updated?

N/A