Skip to content
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

Load Roslyn DevKit assemblies into the default ALC #71807

Merged
merged 1 commit into from
Jan 26, 2024

Conversation

dibarbet
Copy link
Member

@dibarbet dibarbet commented Jan 25, 2024

Resolves #71101

This allows extensions to use the host instance of an assembly if they do not ship their own copy. This did not work previously because the Roslyn DevKit assemblies were loaded into a separate ALC. Now that we ship devkit assemblies in the extension alongside the server, it is safe to load them in the default ALC.

For example, an extension can now access the same instance of VS telemetry that the host has created (and use its telemetry session).
Untitled

Requires client side PR dotnet/vscode-csharp#6831

@dibarbet dibarbet requested a review from a team as a code owner January 25, 2024 18:54
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Jan 25, 2024
Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

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

Seeing this PR makes me want to clean up so much more of our assembly loading/MEF magic.

@@ -31,7 +24,7 @@ private AssemblyLoadContextWrapper(AssemblyLoadContext assemblyLoadContext, Immu
_logger = logger;
}

public static bool TryLoadExtension(string assemblyFilePath, ILogger? logger, [NotNullWhen(true)] out Assembly? assembly)
public static bool TryLoadExtension(string assemblyFilePath, ILogger logger, [NotNullWhen(true)] out Assembly? assembly)
Copy link
Member

Choose a reason for hiding this comment

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

Why does this even take a ILogger if we also passed a logger into this class in the constructor?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is static - there is a wrapper instance for each extension, which gets its logger from the parameter here.

{
try
{
var loadContext = CreateLoadContext(name);
logger.LogTrace("[{name}] Loading assemblies in {assembliesDirectoryPath}", name, assembliesDirectoryPath);
Copy link
Member

Choose a reason for hiding this comment

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

Didn't want to just use interpolated strings?

Copy link
Member Author

@dibarbet dibarbet Jan 25, 2024

Choose a reason for hiding this comment

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

theres actually a diagnostic if you do that. See https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2254
I noticed that this file already did it the 'correct' way, so stuck with that here.

{
Description = "Full paths of extension assemblies to load (optional).",
Required = false
};

var devKitDependencyPathOption = new CliOption<string?>("--devKitDependencyPath")
Copy link
Member

Choose a reason for hiding this comment

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

Nit, but potentially confusing otherwise: should this be a devKitDependenciesPath? Since there's multiple things in the folder?

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe? I chose non-plural because there is a single dependency project. Not sure

This allows extensions to use the host instance of an assembly if they
do not ship their own copy
@dibarbet dibarbet merged commit 2289840 into dotnet:main Jan 26, 2024
28 checks passed
@dibarbet dibarbet deleted the server_dll branch January 26, 2024 00:16
@ghost ghost added this to the Next milestone Jan 26, 2024
@Cosifne Cosifne modified the milestones: Next, 17.10 P1 Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug] Only allow a single instance of VS telemetry in the language server
3 participants