Reduce main thread switches in VisualStudioProjectFactory.CreateAndAddToWorkspaceAsync #77920

ToddGrun · 2025-03-31T20:14:43Z

This method is called once for each project in the solution during solution open, and each call was essentially switching to the main thread twice (once explicitly, once via call to _visualStudioWorkspaceImpl.RefreshProjectExistsUIContextForLanguageAsync). For my testing of opening Roslyn.sln, this removed over 600 main thread switches.

Instead:

Move the first main thread switch to just occur once in an initialization task. This task is joined when CreateAndAddToWorkspaceAsync is invoked to ensure that that initialization is completed.
Move the second main thread switch to instead only occur when the known uicontext state would have it's active state changed. This essentially only happens when opening the first or closing the last project for a language.

…dToWorkspaceAsync This method is called once for each project in the solution during solution open, and each call was essentially switching to the main thread twice (once explicitly, once via call to _visualStudioWorkspaceImpl.RefreshProjectExistsUIContextForLanguageAsync). For my testing of opening Roslyn.sln, this removed over 600 main thread switches. Instead: 1) Move the first main thread switch to just occur once in an initialization task. This task is joined when CreateAndAddToWorkspaceAsync is invoked to ensure that that initialization is completed. 2) Move the second main thread switch to instead move inside the callback from an ABWQ. The code being called needs the UI thread, but doesn't need to occur synchronously during the call to CreateAndAddToWorkspaceAsync.

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs

jasonmalinowski

There's a bug around loading a different solution.

jasonmalinowski · 2025-03-31T20:26:14Z

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs

+                // Since we're on the UI thread here anyways, use that as an opportunity to grab the
+                // IVsSolution object and solution file path.
+                var solution = await _solution2.GetValueOrNullAsync(cancellationToken).ConfigureAwait(true);
+                _solutionFilePath = solution != null && ErrorHandler.Succeeded(solution.GetSolutionInfo(out _, out var filePath, out _))
+                    ? filePath
+                    : null;


This will only run once, which will break things badly if the user closes one solution and opens another. That said though, in the last few releases a bunch of the solution-loading mechanics in the shell were rewritten to be managed code, so maybe there's a free-threaded way to get this now. Or this could subscribe to an event and update it whenever that event fires.

I'm curious if this worked before, I'll test it out.

The GetSolutionInfo call would differ after the solution changed. Need to handle that better.

IVsBackgroundSolution seems to work with the project types I've tested which allows obtaining the solution path off the main thread.

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs

jasonmalinowski · 2025-03-31T20:40:20Z

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs

        // Ensure that other VS contexts get accurate information that the UIContext for this language is now active.
-        // This is not cancellable as we have already mutated the solution.
-        await _visualStudioWorkspaceImpl.RefreshProjectExistsUIContextForLanguageAsync(language, CancellationToken.None);
+        _uiContextUpdateWorkQueue.AddWork(language);


I'm not sure if asynchronously updating this will cause issues, or whether we had a (soft) guarantee that when we return the context would be set. But there might be an even better approach here: we only need to update the contexts when the number of projects will go from zero to non-zero during a load. Which in our case of loading Roslyn as a benchmark would be a grand total of two. So maybe a small tweak to simply have it realize the update isn't necessary in the first place might be even better.

It feels like the only way to know whether the update is necessary is to check the state of the UIContext, which would need to be done on the UI thread. It doesn't seem like just keeping track if we go to/from zero projects with the language name would handle cases where other code could change that UIContext's state.

I'm not seeing where this is even used (other than tests). Is there somewhere with IVT that is using these flags?

@jasonmalinowski -- do you have a preference between:

Loosen the requirement that uicontext.IsActive is set during CreateAndAddToWorkspaceAsync execution. Change the integration tests that look like they might rely on this to instead do a WaitForAllAsyncOperationsAsync.

Change RefreshProjectExistsUIContextForLanguageAsync to assume that no one else changes the UIContext.IsActive state and have it set the value when the number of projects for a language switches to/from zero.

Something else

I personally prefer 1 since I can't find any other users of these UIContexts, but I'm not too opinionated.

The UI contexts are used for things like enabling/disabling commands, and also to help with other components that want to be able to ask "is there a C# project even there before I load up all my Roslyn support?" for things like test explorer. We're the only one who should be setting it so this assumption:

to assume that no one else changes the UIContext.IsActive state

Is completely fine to assume I'd say.

I'd be worried about weakening the support because it could have downstream ramifications -- package loads and such can trigger on UIContexts being changed, and delaying that on some time delay could break integration tests, including divisional tests.

That said, if 2 is hard to write, maybe 1 is just the easier option.

I missed this question:

Is there somewhere with IVT that is using these flags?

Anything can use the GUID for the context to ask if that context is active. I'm not sure if the GUIDs got formally documented but any other repo could have it.

Tried out 2), let me know if you were thinking along a different line for it.

Note that only calls to CreateAndAddToWorkspaceAsync that will change the UIContext state wait for it to update before returning. Is this acceptable?

Note that only calls to CreateAndAddToWorkspaceAsync that will change the UIContext state wait for it to update before returning. Is this acceptable?

@jasonmalinowski -- this is my only remaining concern. Is this acceptable?

My apologies I had missed that question.

That is a potential concern. My worry about this was mostly if this could introduce flakiness to integration tests -- some integration test loads a project, and then does something that implicitly checks the UI context and then fails if this hasn't been updated yet.

What might work, instead of just doing SwitchToMainThread outside the lock, instead have a JoinableTaskCollection where we can add a task to; everything always waits for that collection to be empty before returning.

CA(true) to avoid thread jumping

…ovider to avoid a null bang

…ctFactory.CreateAndAddToWorkspaceAsync

… ABWQ any more

jasonmalinowski · 2025-04-02T19:45:51Z

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs

+                _visualStudioWorkspaceImpl.SubscribeExternalErrorDiagnosticUpdateSourceToSolutionBuildEvents();
+                _visualStudioWorkspaceImpl.SubscribeToSourceGeneratorImpactingEvents();
+
+                return await _vsixAnalyzerProviderFactory.GetOrCreateProviderAsync(cancellationToken).ConfigureAwait(true);


You could switch this to ConfigureAwait(false), as otherwise you're going to pay for a switch back to the UI thread just to do the return.

full disclosure: I have a tendency to get CA calls wrong.

Given that, and that GetOrCreateProviderAsync does all it's work on the main thread, isn't a CA(true) here going to prevent a thread switch back to the thread pool? If it was CA(false), then it would be a switch back to the thread pool for sure, right?

jasonmalinowski · 2025-04-02T19:56:12Z

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioWorkspaceImpl.cs

+        {
+            (uiContext, var isContextActive) = _languageToProjectExistsUIContext.GetOrAdd(
+                language,
+                language => (Services.GetLanguageServices(language).GetService<IProjectExistsUIContextProviderLanguageService>()?.GetUIContext(), false));


Is fetching the UI context itself free-threaded? I feel like when this was originally written that wasn't the case.

(and if it's not, the fix is simple to just defer that bit to the UI thread...)

And also frankly now since we're avoiding unnecessary updates, you could just remove the UIContext from the map entirely, since we're only going to fetch it 'rarely'.

I thought so because of this comment:

https://devdiv.visualstudio.com/DevDiv/_git/VS?path=/src/env/shell/PackageFramework/Framework/UIContextImpl.cs&version=GBmain&_a=contents&line=63&lineStyle=plain&lineEnd=70&lineStartColumn=1&lineEndColumn=1

Although I do believe this is safe because of the comment linked to above, I do prefer your idea of just retrieving the UIContext while on the main thread, instead of caching it. It simplifies the data structures, and the removes the dependency that creating the ui context is free threaded.

jasonmalinowski

Looks good, but let's double check that UIContext is safe to grab off the UI thread.

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioWorkspaceImpl.cs

2) Update comment to reflect why a value calculated before a thread switch isn't used.

ToddGrun · 2025-04-03T16:38:32Z

Changed to no longer cache the UIContext and just grab it while on the UI thread and it's needed.

In reply to: 2737437422

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioWorkspaceImpl.cs

jasonmalinowski · 2025-04-03T20:35:18Z

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs

        // Ensure that other VS contexts get accurate information that the UIContext for this language is now active.
-        // This is not cancellable as we have already mutated the solution.
-        await _visualStudioWorkspaceImpl.RefreshProjectExistsUIContextForLanguageAsync(language, CancellationToken.None);
+        _uiContextUpdateWorkQueue.AddWork(language);


My apologies I had missed that question.

That is a potential concern. My worry about this was mostly if this could introduce flakiness to integration tests -- some integration test loads a project, and then does something that implicitly checks the UI context and then fails if this hasn't been updated yet.

What might work, instead of just doing SwitchToMainThread outside the lock, instead have a JoinableTaskCollection where we can add a task to; everything always waits for that collection to be empty before returning.

…rojectExistsUIContextForLanguageAsync

jasonmalinowski

jasonmalinowski · 2025-04-03T22:27:07Z

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioWorkspaceImpl.cs

+
+    private async Task UpdateUIContextAsync(string language, CancellationToken cancellationToken)
    {
        await _threadingContext.JoinableTaskFactory.SwitchToMainThreadAsync(alwaysYield: true, cancellationToken);


Do we still want/need the alwaysYield: true? It does mean this will never run inline in RefreshProjectExistsUIContextForLanguageAsync, but does mean that we'll take an extra transition if we might have already been on the UI thread....

I'd prefer to keep it. I see this method always entered on a bg thread. I'd like to limit the amount of time that I'm holding onto _gate.

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioWorkspaceImpl.cs

CyrusNajmabadi · 2025-04-04T01:21:34Z

i thought we weren't using dev17.15 anymore?

ToddGrun · 2025-04-04T01:28:08Z

i thought we weren't using dev17.15 anymore?

whoops! Here's the PR for it to main: #77998

…dToWorkspaceAsync (#77920) (#77998) * Reduce main thread switches in VisualStudioProjectFactory.CreateAndAddToWorkspaceAsync This method is called once for each project in the solution during solution open, and each call was essentially switching to the main thread twice (once explicitly, once via call to _visualStudioWorkspaceImpl.RefreshProjectExistsUIContextForLanguageAsync). For my testing of opening Roslyn.sln, this removed over 600 main thread switches. Instead: 1) Move the first main thread switch to just occur once in an initialization task. This task is joined when CreateAndAddToWorkspaceAsync is invoked to ensure that that initialization is completed. 2) Move the second main thread switch to instead move inside the callback from an ABWQ. The code being called needs the UI thread, but doesn't need to occur synchronously during the call to CreateAndAddToWorkspaceAsync.

* Addressing feedback * Addressing PR feedback * Addressing PR comments * Remove workaround for dotnet/msbuild#10306 The VS SDK was fixed, so the problem shouldn't occur anymore. * move to a workspace factory * No need for solution * Simplify handlers * Add helper * move more over * move more over * Add remove calls * Move handlers over * Move remote service over * async lock * async lock * async lock * More work * Fixup * Correct * Move to immutable dictionary * in progress * in progress * in progress * in progress * in progress * in progress * Simplify * Serialize * simplify * simplify * simplify * in progress * in progress * Reset code * Clelar * renames * Simplify * rename * No more null * Simplify * Exception throwing * Extensions: update feature status (#77923) * Add ignored directives feature status (#77965) * Extensions: misc checks on receiver parameter and extension members (#77937) * Add porject back in * CHange how locking works * Simplify * Docs * Add new message for getting registered method names * IN progres * in progress * Simplify * Simplify * Handle exceptions * Simplify * Docs * move method * Simplify and regions * Tweaks * Docs * Break into files * Simplify exception handling * Simplify * Simplify * Move * Docs * Simplify * Simplify * Share code * Split into local and remote calls * Add throw * Add throw * Simplify * Simplify * Simplify * Simplify * Simplify * Simplify * Simplify * Simplify * Simplify * Simplify * Simplify * Simplify * Avoid potential disposal exception during MEF shutdown (#77990) Previously, if VS was shutdown before Workspace.EnsureEventListeners was invoked, we would cause an exception during MEF disposal. This would happen because our workspace disposal would attempt to get a service that hadn't already been cached, and thus would ask MEF to compose the item during MEF disposal (which doesn't work). Instead, just cache the IWorkspaceEventListenerService for use during the dispose. * Remove unused elements form PublishData.json (#77994) Removing some elements that seem to be left over from how the publish tooling used to work * Reduce main thread switches in VisualStudioProjectFactory.CreateAndAddToWorkspaceAsync (#77920) * Reduce main thread switches in VisualStudioProjectFactory.CreateAndAddToWorkspaceAsync This method is called once for each project in the solution during solution open, and each call was essentially switching to the main thread twice (once explicitly, once via call to _visualStudioWorkspaceImpl.RefreshProjectExistsUIContextForLanguageAsync). For my testing of opening Roslyn.sln, this removed over 600 main thread switches. Instead: 1) Move the first main thread switch to just occur once in an initialization task. This task is joined when CreateAndAddToWorkspaceAsync is invoked to ensure that that initialization is completed. 2) Move the second main thread switch to instead move inside the callback from an ABWQ. The code being called needs the UI thread, but doesn't need to occur synchronously during the call to CreateAndAddToWorkspaceAsync. * Explicitly releasE * Cancellation is fine * Reorder * remove net * docs * docs * remove exception handling * Add public api * lint * Reduce main thread switches in VisualStudioProjectFactory.CreateAndAddToWorkspaceAsync (#77920) (#77998) * Reduce main thread switches in VisualStudioProjectFactory.CreateAndAddToWorkspaceAsync This method is called once for each project in the solution during solution open, and each call was essentially switching to the main thread twice (once explicitly, once via call to _visualStudioWorkspaceImpl.RefreshProjectExistsUIContextForLanguageAsync). For my testing of opening Roslyn.sln, this removed over 600 main thread switches. Instead: 1) Move the first main thread switch to just occur once in an initialization task. This task is joined when CreateAndAddToWorkspaceAsync is invoked to ensure that that initialization is completed. 2) Move the second main thread switch to instead move inside the callback from an ABWQ. The code being called needs the UI thread, but doesn't need to occur synchronously during the call to CreateAndAddToWorkspaceAsync. * make nested * Simplify * Simplify * Simplify * Simplify * Simplify * restore * Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250402.2 (#77982) Microsoft.SourceBuild.Intermediate.source-build-reference-packages From Version 10.0.618101 -> To Version 10.0.620202 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * Allow null * Simplify * No VoidResult * Make everything non-capturing * 'nameof(T<>)' not supported yet. * Update references * Revert "Another attempt to move MiscellaneousFilesWorkspace to a bg thread (#77983) This reverts commit 2e8fcbe. * fix * Exception work * Update Roslyn.sln * More exception work * Add remote end * Complete the exception handling work * Add docs * docs * Add docs * Rename type * Rename type * update publishdata * Change SolutionState.ProjectStates from an ImmutableDictionary<ProjectId, ProjectState> to an ImmutableArray<ProjectState> (#77971) * *** WIP. Definitely needs supporting speedometer numbers before being considered *** Change SolutionState to keep/expose and ImmutableArray<ProjectState> instead of an IReadOnlyList<ProjectId> By exposing the project states, there is a bunch of code that can be changed to enumerate over that collection rather than over the values of an ImmutableDictionary<ProjectId, ProjectState>. That enumeration is actually *very* expensive. For example, during roslyn load, local etl traces indicates the following CPU usage enumerating this dictionary: Under ComputeDocumentIdsWithFilePath: 2.6 seconds Under GetFirstRelatedDocumentId: 1.1 seconds There is a bit of a tradeoff associated with this change. The IReadOnlyList<ProjectId> could be reused very often, whereas there is much less opportunity for sharing ImmutableArray<ProjectState> when forking the solution state. I expect there to be more memory allocated in the speedometer runs, so I'd like to get a feel on how much worse that is before elevating this PR out of draft status. Additionally, SolutionState had a CWT over a sorted version of this IReadOnlyList<ProjectId>. As mentioned earlier, the sharing of this data is quite a bit less common now that it's an ImmutableArray<ProjectState>. I locally measured the stopwatch time spent always sorting this data in ComputeChecksumsAsync and it was a total of 4 ms (averaged over two separate VS runs) when loading the roslyn sln. The ImmutableDictionary is still present in SolutionState, but it was renamed to indicate that it's primarily useful as a lookup tool, and all references treating it as an enumeration mechanism were changed to instead use the ImmutableArray<ProjectState>. * Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250404.2 (#78008) Microsoft.SourceBuild.Intermediate.source-build-reference-packages From Version 10.0.620202 -> To Version 10.0.620402 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * Fix VSTypeScript lsp tests * localize servicehub service name * Simplify workspace initialization in the LSP server Right now we have the logic for which analyzers get added to a workspace in Program.cs, which calls a special method that specifically initializes the main host workspace. This refactors it so that could be used to initialize any workspace, and removes any tricky ordering problems that might happen by using cleaner MEF imports when we have them. * Update test * Update dependencies from https://github.com/dotnet/arcade build 20250404.5 Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.XliffTasks From Version 9.0.0-beta.25164.2 -> To Version 9.0.0-beta.25204.5 * Update maintenance-packages versions (#78005) * Update maintenance-packages versions * Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250404.2 Microsoft.SourceBuild.Intermediate.source-build-reference-packages From Version 10.0.620202 -> To Version 10.0.620402 * Address feedback --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * Fix EA layering for Razor.ExternalAccess (#77927) Moves things to /Shared to ship in both MS.CA.EA.Razor and MS.CA.EA.Razor.Features At some point we can rename MS.CA.EA.Razor to MS.CA.EA.Razor.EditorFeatures but I didn't bother with that in this PR Shipping in both to not require dual insertion. We can fix this after a consuming change in Razor is inserted * Delete * Update PublishData.json after VS snap to rel/d17.14 * Handle nameof(indexer) in ref analysis (#78015) * Make a couple of features non-experimental * Ensure external access extensions package gets codebase * Feedback * Add extension message handler service teest * Add extension message handler service test * FIx * Add testS * In progress * Test work * Tests * Add test * More tests * Add tests * Add tests * Add tests * Add test * Add test * Add test * Add test * Add test * Update comment * Disable TransitiveVersioningPinning for RoslynAnalyzers. * Remove dependency on EditorFeatures from lsp tests * Remove dependency on EditorFeatures from codelens layer * Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250407.2 Microsoft.SourceBuild.Intermediate.source-build-reference-packages From Version 10.0.620402 -> To Version 10.0.620702 * Remove dependency on EditorFeatures from build tools * Update dependency versions * Extensions: ref safety analysis (#77967) * Update PublishData.json after VS span to main * In progress * Fix crash in backing field nullability cycle scenario (#77993) * More work * Pass along when an extension was unloaded * Add teset * Add tests * Docs * Simplify * Using alias * Fix * Add tests * Add docs * Update gladstone/roslyn api * Simplify channels in SemanticSearch * Semantic Search: Add support for async queries and FAR tool (#77906) * Simplify further * Simplify further * Localize exception messages * Docs * Docs * Docs * named args * named args * Docs * Move type * Docs * Fix name * Compile just for NET * Unseal LSP types (#78041) * Simplify analyzer api * Update RoslynAnalyzer package projects with dependencies This will fix issues with transitive pinning during source builds. * Ensure LSP uses actual signature help trigger characters * Improve detection of code whose updates may not have effect (#78009) * Do not return metadata names for document symbols * Fix nullability warnings * Review feedback * Remove EditorFeatures from OOP (#78069) * Add back EA.Razor for servicing branches publishdata is pulled from main always. this needs to be present even though the package no longer exists for servicing branches * Remove unused ISemanticSearchWorkspaceHost (#78083) * Split query execution into compile and execute calls (#78081) * Update resourceManagement.yml (#77948) * Expression trees: support optional arguments and named arguments in parameter order (#77972) * Update ignored directives public API (#77968) * Remove experiment * Add Content token to IgnoredDirectiveTriviaSyntax * Add Content token to ShebangDirectiveTriviaSyntax * Fixup public API * Fixup semantic search API list * Fix CLI flag in error message * Remove Update API * Update SemanticSearch API list --------- Co-authored-by: Matteo Prosperi <maprospe@microsoft.com> Co-authored-by: Jason Malinowski <jason.malinowski@microsoft.com> Co-authored-by: Cyrus Najmabadi <cyrus.najmabadi@gmail.com> Co-authored-by: Cyrus Najmabadi <cyrusn@microsoft.com> Co-authored-by: Julien Couvreur <julien.couvreur@gmail.com> Co-authored-by: Jan Jones <janjones@microsoft.com> Co-authored-by: Matteo Prosperi <41970398+matteo-prosperi@users.noreply.github.com> Co-authored-by: Todd Grunke <toddgrun@microsoft.com> Co-authored-by: Jared Parsons <jared@paranoidcoding.org> Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: David Barbet <dabarbet@microsoft.com> Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com> Co-authored-by: Andrew Hall <andrha@microsoft.com> Co-authored-by: Charles Stoner <10732005+cston@users.noreply.github.com> Co-authored-by: Tomas Matousek <tomat@microsoft.com> Co-authored-by: Joey Robichaud <jorobich@microsoft.com> Co-authored-by: Rikki Gibson <rigibson@microsoft.com> Co-authored-by: Tomáš Matoušek <tmat@users.noreply.github.com>

ToddGrun requested a review from CyrusNajmabadi March 31, 2025 20:14

ToddGrun requested a review from a team as a code owner March 31, 2025 20:14

ghost added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Mar 31, 2025

CyrusNajmabadi reviewed Mar 31, 2025

View reviewed changes

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs Show resolved Hide resolved

CyrusNajmabadi reviewed Mar 31, 2025

View reviewed changes

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs Show resolved Hide resolved

CyrusNajmabadi reviewed Mar 31, 2025

View reviewed changes

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProjectFactory.cs Outdated Show resolved Hide resolved

jasonmalinowski requested changes Mar 31, 2025

View reviewed changes

ToddGrun added 7 commits March 31, 2025 13:51

Just use ABWQ cancellation token

e75e53b

CA(true) to avoid thread jumping

Use IVsBackgroundSolution to query solution file name

4b81ab6

Add comment around passing alwaysYields to SwitchToMainThreadAsync

9288c48

Change initialization task to return VisualStudioDiagnosticAnalyzerPr…

ce03dd9

…ovider to avoid a null bang

Ensure UIContext.IsActive is set upon completion of VisualStudioProje…

5ef81b7

…ctFactory.CreateAndAddToWorkspaceAsync

No longer need IAsynchronousOperationListenerProvider as not using an…

2817eaf

… ABWQ any more

Bit more cleanup

5aca293

jasonmalinowski reviewed Apr 2, 2025

View reviewed changes

jasonmalinowski approved these changes Apr 2, 2025

View reviewed changes

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioWorkspaceImpl.cs Show resolved Hide resolved

1) Change dictionary to hold bool instead of tuple

8d125b4

2) Update comment to reflect why a value calculated before a thread switch isn't used.

build-analysis bot mentioned this pull request Apr 3, 2025

The active test run was aborted. Reason: Test host process crashed dotnet/dnceng#451

Closed

3 tasks

jasonmalinowski approved these changes Apr 3, 2025

View reviewed changes

Ensure the ui context is fully updated before returning from RefreshP…

742ab9c

…rojectExistsUIContextForLanguageAsync

jasonmalinowski approved these changes Apr 3, 2025

View reviewed changes

src/VisualStudio/Core/Def/ProjectSystem/VisualStudioWorkspaceImpl.cs Show resolved Hide resolved

more comments

a0a8af3

ToddGrun merged commit 15e0c3c into dotnet:release/dev17.15 Apr 4, 2025
25 checks passed

This was referenced Apr 19, 2025

[Automated] PRs inserted in VS build main-10518.29 #78209

Closed

[Automated] PRs inserted in VS build feature.debugger.main-10521.160 #78252

Closed

dotnet-bot mentioned this pull request May 31, 2025

[Automated] PRs inserted in VS build feature.telemetry.d18OpenTelemetry-10630.96 #78782

Closed

Reduce main thread switches in VisualStudioProjectFactory.CreateAndAddToWorkspaceAsync #77920

Reduce main thread switches in VisualStudioProjectFactory.CreateAndAddToWorkspaceAsync #77920

Uh oh!

Conversation

ToddGrun commented Mar 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jasonmalinowski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jasonmalinowski Mar 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jasonmalinowski left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ToddGrun commented Apr 3, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jasonmalinowski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

CyrusNajmabadi commented Apr 4, 2025

Uh oh!

ToddGrun commented Mar 31, 2025 •

edited

Loading

jasonmalinowski Mar 31, 2025 •

edited

Loading