Skip to content

Extract base LanguageServerProjectLoader from LanguageServerProjectSystem #78329

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

RikkiGibson
Copy link
Member

The first commit renames file LanguageServerProjectSystem.cs to LanguageServerProjectLoader.cs.
The second commit re-creates LanguageServerProjectSystem.cs with new content.
You may find commit-by-commit review easier.

LanguageServerProjectLoader contains most of the logic from before. LanguageServerProjectSystem contains methods specifically for opening solutions and projects.

When we do file-based programs, we will introduce a new project system type, which has a method for opening a file-based program project.

Also, we explicitly stop storing LanguageServerWorkspaceFactory, and instead pass in the specific bits from it that we were using, because eventually LanguageServerWorkspaceFactory will hold both a file-based program workspace and the pre-existing host workspace.

@RikkiGibson RikkiGibson requested a review from a team as a code owner April 25, 2025 23:39
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Infrastructure untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 25, 2025

namespace Microsoft.CodeAnalysis.LanguageServer.HostWorkspace;

internal abstract class LanguageServerProjectLoader
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't expect this would be an abstract type, but rather a MEF component. if nothing else, that binary log numeric suffix should probably be shared across the different users.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternately we could move that shared state to a separate MEF type so that bit it shared, and that's it. I guess that'll make things simpler in terms of not having to move so much state to the ProjectToLoad type.


protected readonly AsyncBatchingWorkQueue<ProjectToLoad> _projectsToLoadAndReload;

protected readonly ProjectSystemProjectFactory _projectFactory;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's protected then this shouldn't have a _ underscore. But that said I'd expect this to go away if this becomes a single service via MEF, and this moves to the work items being queued.

private readonly IFileChangeWatcher _fileChangeWatcher;
private readonly IGlobalOptionService _globalOptionService;
protected readonly ILoggerFactory _loggerFactory;
protected readonly ILogger _logger;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep this private, other components can make their own. Or expect the caller to pass it down, since that way it can specify which derived type it is.

/// <summary>
/// A single gate for code that is adding work to <see cref="_projectsToLoadAndReload" />. This is just we don't have code simultaneously trying to load and unload solutions at once.
/// </summary>
protected readonly SemaphoreSlim _gate = new SemaphoreSlim(initialCount: 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This being protected is pretty strange -- seems like there should be a method to call that keeps this and the actual queue private. That comment I don't think makes sense though, given we don't actually have any unloading happening, so maybe just delete that while you're here while laughing at me for writing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Infrastructure untriaged Issues and PRs which have not yet been triaged by a lead VSCode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants