Another attempt to move MiscellaneousFilesWorkspace to a bg thread #77768
Conversation
This previously failed with integration test failures. I attribute this to previously trying to move the VisualStudioMetadataReferenceManager when that very much wants to be on the main thread. Instead, just ensure that the code that creates the VisualStudioMetadataReferenceManager is on the main thread when that value is needed (it already was). 1) Move MiscellaneousFilesWorkspace to bg thread MEF construction 2) Move HostServicesProvider to location of VisualStudioMefHostServices and use in a couple places (this prevents MiscellaneousFilesWorkspace from needing to MEF import VisualStudioWorkspace in it's ctor)
dotnet-issue-labeler
bot
added
Area-IDE
untriaged
… unit test changes
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
| IMetadataAsSourceFileService fileTrackingMetadataAsSourceService, | ||
| VisualStudioWorkspace visualStudioWorkspace) | ||
| : base(visualStudioWorkspace.Services.HostServices, WorkspaceKind.MiscellaneousFiles) | ||
| Lazy<IMetadataAsSourceFileService> fileTrackingMetadataAsSourceService, |
There was a problem hiding this comment.
Why making the IMetadataAsSourceFileService lazy? Was there some other hidden UI thread dependency there, or it's just a generally big service and there's no reason to ask for it early? A comment might be good either way.
There was a problem hiding this comment.
I'd like to flip that question and rather us question why parameters aren't lazy in the package load path. This one switched over to being lazy pretty easily, so I did.
| // VisualStudioMetadataReferenceManager construction requires the main thread | ||
| _threadingContext.ThrowIfNotOnUIThread(); |
There was a problem hiding this comment.
Do we have a bug tracking fixing this already? It'd be good to link to this to make sure we don't forget to clean it up later.
There was a problem hiding this comment.
Went ahead and created something:
| // Potential calculation of _metadataReferences requires being on the main thread | ||
| _threadingContext.ThrowIfNotOnUIThread(); |
There was a problem hiding this comment.
Same as above: consider adding a comment here to wahtever bug we have tracking cleaning this up.
This previously failed with integration test failures. I attribute this to previously trying to move the VisualStudioMetadataReferenceManager to bg thread construction when that very much wants to be on the main thread. Instead, just ensure that the code that creates the VisualStudioMetadataReferenceManager is on the main thread when that value is needed (it already was).