Ajouter une extension du protocole de serveur de langue
Le protocole Language Server Protocol (LSP) est un protocole commun, sous la forme de JSON RPC v2.0, utilisé pour fournir des fonctionnalités de service de langage à différents éditeurs de code. À l’aide du protocole, les développeurs peuvent écrire un serveur de langage unique pour fournir des fonctionnalités de service de langage telles qu’IntelliSense, les diagnostics d’erreur, rechercher toutes les références, et ainsi de suite, dans différents éditeurs de code qui prennent en charge le LSP. Traditionnellement, les services linguistiques dans Visual Studio peuvent être ajoutés à l’aide de fichiers de grammaire TextMate pour fournir des fonctionnalités de base telles que la mise en surbrillance de la syntaxe ou l’écriture de services de langage personnalisés qui utilisent l’ensemble complet d’API d’extensibilité Visual Studio pour fournir des données plus riches. Avec la prise en charge de Visual Studio pour LSP, il existe une troisième option.
Pour garantir la meilleure expérience utilisateur possible, envisagez également d’implémenter language Configuration, qui fournit un traitement local de plusieurs des mêmes opérations et peut donc améliorer les performances de nombreux opérations d’éditeur spécifiques à la langue prises en charge par le LSP.
Protocole du serveur de langage
Cet article explique comment créer une extension Visual Studio qui utilise un serveur de langage basé sur LSP. Il part du principe que vous avez déjà développé un serveur de langage basé sur LSP et que vous souhaitez simplement l’intégrer à Visual Studio.
Pour la prise en charge dans Visual Studio, les serveurs de langage peuvent communiquer avec le client (Visual Studio) via n’importe quel mécanisme de transmission basé sur le flux, par exemple :
- Flux d’entrée/sortie standard
- Canaux nommés
- Sockets (TCP uniquement)
L’intention du LSP et de la prise en charge de celui-ci dans Visual Studio consiste à intégrer des services linguistiques qui ne font pas partie du produit Visual Studio. Il n’est pas destiné à étendre les services de langage existants (comme C#) dans Visual Studio. Pour étendre les langues existantes, reportez-vous au guide d’extensibilité du service de langage (par exemple, le « Roslyn » .NET Compiler Platform) ou consultez Étendre l’éditeur et les services linguistiques.
Pour plus d’informations sur le protocole lui-même, consultez la documentation ici.
Pour plus d’informations sur la création d’un exemple de serveur de langage ou sur l’intégration d’un serveur de langage existant dans Visual Studio Code, consultez la documentation ici.
Fonctionnalités prises en charge par le protocole Language Server
Les tableaux suivants indiquent quelles fonctionnalités LSP sont prises en charge dans Visual Studio :
| Message | Prise en charge dans Visual Studio 2022 |
|---|---|
| initialiser | oui |
| initialisé | oui |
| arrêt | oui |
| sortie | oui |
| $/cancelRequest | oui |
| fenêtre/afficherMessage | oui |
| window/showMessageRequest | oui |
| window/logMessage | oui |
| données de télémétrie/événement | |
| client/registerCapability | |
| client/unregisterCapability | |
| workspace/didChangeConfiguration | oui |
| workspace/didChangeWatchedFiles | oui |
| espace de travail/symbole | oui |
| workspace/executeCommand | oui |
| workspace/applyEdit | oui |
| textDocument/publishDiagnostics | oui |
| textDocument/didOpen | oui |
| textDocument/didChange | oui |
| textDocument/willSave | |
| textDocument/willSaveWaitUntil | |
| textDocument/didSave | oui |
| textDocument/didClose | oui |
| textDocument/completion | oui |
| achèvement/résolution | oui |
| textDocument/hover | oui |
| textDocument/signatureHelp | oui |
| textDocument/references | oui |
| textDocument/documentHighlight | oui |
| textDocument/documentSymbol | oui |
| textDocument/mise en forme | oui |
| textDocument/rangeFormatting | oui |
| textDocument/onTypeFormatting | |
| textDocument/definition | oui |
| textDocument/codeAction | oui |
| textDocument/codeLens | |
| codeLens/resolve | |
| textDocument/documentLink | |
| documentLink/resolve | |
| textDocument/rename | oui |
Démarrer
Remarque
À compter de Visual Studio 2017 version 15.8, la prise en charge du protocole Common Language Server est intégrée à Visual Studio. Si vous avez créé des extensions LSP à l’aide de la préversion version VSIX du client language Server VSIX, elles cesseront de fonctionner une fois que vous effectuez une mise à niveau vers la version 15.8 ou ultérieure. Vous devez effectuer les opérations suivantes pour que vos extensions LSP fonctionnent à nouveau :
Désinstallez le protocole de serveur de langue Microsoft Visual Studio Language Server Protocol Preview VSIX.
À compter de la version 15.8, chaque fois que vous effectuez une mise à niveau dans Visual Studio, la préversion de VSIX est automatiquement détectée et supprimée.
Mettez à jour votre référence Nuget vers la dernière version non préliminaire des packages LSP .
Supprimez la dépendance à Microsoft Visual Studio Language Server Protocol Preview VSIX dans votre manifeste VSIX.
Vérifiez que votre VSIX spécifie Visual Studio 2017 version 15.8 Preview 3 comme limite inférieure pour la cible d’installation.
Reconstruire et redéployer.
Créer un projet VSIX
Pour créer une extension de service de langage à l’aide d’un serveur de langage basé sur LSP, vérifiez d’abord que vous disposez de la développement d’extension Visual Studio Charge de travail installée pour votre instance de VS.
Ensuite, créez un projet VSIX en accédant à Fichier>Nouveau projet>Visual C#>Extensibilité>projet VSIX:
Serveur de langage et installation du runtime
Par défaut, les extensions créées pour prendre en charge les serveurs de langage basés sur LSP dans Visual Studio ne contiennent pas les serveurs de langage eux-mêmes ou les runtimes nécessaires pour les exécuter. Les développeurs d’extensions sont responsables de la distribution des serveurs de langage et des runtimes nécessaires. Il existe plusieurs façons de procéder :
- Les serveurs de langage peuvent être incorporés dans VSIX en tant que fichiers de contenu.
- Créez une msi pour installer le serveur de langue et/ou les runtimes nécessaires.
- Fournissez des instructions sur la Place de marché en informant les utilisateurs comment obtenir des runtimes et des serveurs linguistiques.
Fichiers de grammaire TextMate
Le LSP n’inclut pas de spécification sur la façon de fournir la colorisation du texte pour les langues. Pour fournir une colorisation personnalisée pour les langages dans Visual Studio, les développeurs d’extensions peuvent utiliser un fichier de grammaire TextMate. Pour ajouter des fichiers de grammaire ou de thème TextMate personnalisés, procédez comme suit :
Créez un dossier nommé « Grammaires » à l’intérieur de votre extension (ou il peut s’agir du nom que vous choisissez).
Dans le dossier Grammars, incluez tous les fichiers correspondant à *.tmlanguage, *.plist, *.tmthemeou à un format de votre choix *.json qui fournissent une colorisation personnalisée.
Conseil
Un fichier .tmtheme définit la façon dont les étendues sont mappées aux classifications Visual Studio (clés de couleur nommées). Pour obtenir des conseils, vous pouvez consulter le fichier global .tmtheme dans le répertoire %ProgramFiles(x86)%\Microsoft Visual Studio\<version>\<SKU>\Common7\IDE\CommonExtensions\Microsoft\TextMate\Starterkit\Themesg.
Créez un fichier .pkgdef et ajoutez une ligne similaire à celle-ci :
[$RootKey$\TextMate\Repositories] "MyLang"="$PackageFolder$\Grammars"Cliquez avec le bouton droit sur les fichiers et sélectionnez Propriétés. Modifiez l'action Build en Contenu et changez la propriété Include dans VSIX en vrai.
Une fois les étapes précédentes terminées, un dossier Grammars est ajouté au répertoire d’installation du package en tant que source de référentiel nommée « MyLang » (« MyLang » est simplement un nom pour la désambiguation et peut être n’importe quelle chaîne unique). Toutes les grammaires (fichiers .tmlanguage) et les fichiers de thème (fichiers .tmtheme) dans ce répertoire sont récupérés comme potentiels et remplacent les grammaires intégrées fournies avec TextMate. Si les extensions déclarées du fichier de grammaire correspondent à l’extension du fichier en cours d’ouverture, TextMate intervient.
Créer un client de langage simple
Interface principale - ILanguageClient
Après avoir créé votre projet VSIX, ajoutez le ou les packages NuGet suivants à votre projet :
Remarque
Lorsque vous prenez une dépendance sur le package NuGet après avoir effectué les étapes précédentes, les packages Newtonsoft.Json et StreamJsonRpc sont également ajoutés à votre projet. Ne mettez pas à jour ces packages, sauf si vous êtes certain que ces nouvelles versions seront installées sur la version de Visual Studio que votre extension cible. Les assemblys ne seront pas inclus dans votre VSIX ; Au lieu de cela, ils seront récupérés à partir du répertoire d’installation de Visual Studio. Si vous référencez une version plus récente des assemblys que ce qui est installé sur l’ordinateur d’un utilisateur, votre extension ne fonctionnera pas.
Vous pouvez ensuite créer une classe qui implémente l’interface ILanguageClient, qui est l’interface principale nécessaire pour les clients linguistiques se connectant à un serveur de langage basé sur LSP.
Voici un exemple :
namespace MockLanguageExtension
{
[ContentType("bar")]
[Export(typeof(ILanguageClient))]
public class BarLanguageClient : ILanguageClient
{
public string Name => "Bar Language Extension";
public IEnumerable<string> ConfigurationSections => null;
public object InitializationOptions => null;
public IEnumerable<string> FilesToWatch => null;
public event AsyncEventHandler<EventArgs> StartAsync;
public event AsyncEventHandler<EventArgs> StopAsync;
public async Task<Connection> ActivateAsync(CancellationToken token)
{
await Task.Yield();
ProcessStartInfo info = new ProcessStartInfo();
info.FileName = Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "Server", @"MockLanguageServer.exe");
info.Arguments = "bar";
info.RedirectStandardInput = true;
info.RedirectStandardOutput = true;
info.UseShellExecute = false;
info.CreateNoWindow = true;
Process process = new Process();
process.StartInfo = info;
if (process.Start())
{
return new Connection(process.StandardOutput.BaseStream, process.StandardInput.BaseStream);
}
return null;
}
public async Task OnLoadedAsync()
{
await StartAsync.InvokeAsync(this, EventArgs.Empty);
}
public Task OnServerInitializeFailedAsync(Exception e)
{
return Task.CompletedTask;
}
public Task OnServerInitializedAsync()
{
return Task.CompletedTask;
}
}
}
Les principales méthodes à implémenter sont OnLoadedAsync et ActivateAsync. OnLoadedAsync est appelée lorsque Visual Studio a chargé votre extension et que votre serveur de langage est prêt à être démarré. Dans cette méthode, vous pouvez appeler immédiatement le délégué StartAsync pour signaler que le serveur de langage doit être démarré, ou vous pouvez effectuer une logique supplémentaire et appeler StartAsync ultérieurement. Pour activer votre serveur de langue, vous devez appeler StartAsync à un moment donné.
ActivateAsync est la méthode appelée par la suite en appelant le délégué StartAsync. Il contient la logique permettant de démarrer le serveur de langage et d’établir une connexion à celui-ci. Un objet de connexion qui contient des flux pour l’écriture sur le serveur et la lecture à partir du serveur doit être retourné. Toutes les exceptions levées ici sont interceptées et affichées à l’utilisateur via un message InfoBar dans Visual Studio.
Mise en service
Une fois que votre classe cliente de langage est implémentée, vous devez définir deux attributs pour qu’elle définisse la façon dont elle sera chargée dans Visual Studio et activée :
[Export(typeof(ILanguageClient))]
[ContentType("bar")]
MEF
Visual Studio utilise MEF (Managed Extensibility Framework) pour gérer ses points d’extensibilité. L’attribut Export indique à Visual Studio que cette classe doit être récupérée en tant que point d’extension et chargée au moment approprié.
Pour utiliser MEF, vous devez également définir MEF en tant que ressource dans le manifeste VSIX.
Ouvrez votre concepteur de manifeste VSIX et accédez à l’onglet Ressources :
Cliquez sur Nouveau pour créer un nouvel actif :
MEF
- Type: Microsoft.VisualStudio.MefComponent
- Source : Projet dans la solution actuelle
- projet: [Votre projet]
Définition du type de contenu
Actuellement, la seule façon de charger votre extension de serveur de langage basé sur LSP est le type de contenu de fichier. Autrement dit, lors de la définition de votre classe cliente de langage (qui implémente ILanguageClient), vous devez définir les types de fichiers qui, lorsqu’ils sont ouverts, entraînent le chargement de votre extension. Si aucun fichier correspondant à votre type de contenu défini n’est ouvert, votre extension ne sera pas chargée.
Pour ce faire, définissez une ou plusieurs classes ContentTypeDefinition :
namespace MockLanguageExtension
{
public class BarContentDefinition
{
[Export]
[Name("bar")]
[BaseDefinition(CodeRemoteContentDefinition.CodeRemoteContentTypeName)]
internal static ContentTypeDefinition BarContentTypeDefinition;
[Export]
[FileExtension(".bar")]
[ContentType("bar")]
internal static FileExtensionToContentTypeDefinition BarFileExtensionDefinition;
}
}
Dans l’exemple précédent, une définition de type de contenu est créée pour les fichiers qui se terminent par extension de fichier .bar. La définition du type de contenu reçoit le nom « bar » et doit dériver de CodeRemoteContentTypeName.
Après avoir ajouté une définition de type de contenu, vous pouvez définir quand charger votre extension cliente de langage dans la classe cliente de langue :
[ContentType("bar")]
[Export(typeof(ILanguageClient))]
public class BarLanguageClient : ILanguageClient
{
}
L’ajout de la prise en charge des serveurs de langage LSP ne vous oblige pas à implémenter votre propre système de projet dans Visual Studio. Les clients peuvent ouvrir un seul fichier ou un dossier dans Visual Studio pour commencer à utiliser votre service de langage. En fait, la prise en charge des serveurs de langage LSP est conçue pour fonctionner uniquement dans les scénarios de dossier/fichier ouverts. Si un système de projet personnalisé est implémenté, certaines fonctionnalités (telles que les paramètres) ne fonctionnent pas.
Fonctionnalités avancées
Paramètres
La prise en charge des paramètres spécifiques au serveur de langage personnalisé est disponible, mais elle est toujours en cours d’amélioration. Les paramètres sont spécifiques à ce que le serveur de langue prend en charge et contrôlent généralement la façon dont le serveur de langue émet des données. Par exemple, un serveur de langue peut avoir un paramètre pour le nombre maximal d’erreurs signalées. Les auteurs d’extensions définissent une valeur par défaut, qui peut être modifiée par les utilisateurs pour des projets spécifiques.
Suivez ces étapes ci-dessous pour ajouter la prise en charge des paramètres à votre extension de service de langage LSP :
Ajoutez un fichier JSON (par exemple, MockLanguageExtensionSettings.json) à votre projet qui contient les paramètres et leurs valeurs par défaut. Par exemple:
{ "foo.maxNumberOfProblems": -1 }Cliquez avec le bouton droit sur le fichier JSON et sélectionnez Propriétés. Modifiez l'action Build en Contenu et la propriété Include dans VSIX en vrai.
Implémentez ConfigurationSections et retournez la liste des préfixes pour les paramètres définis dans le fichier JSON (dans Visual Studio Code, cela mappe au nom de la section de configuration dans package.json) :
public IEnumerable<string> ConfigurationSections { get { yield return "foo"; } }Ajoutez un fichier .pkgdef au projet (ajoutez un nouveau fichier texte et remplacez l’extension de fichier par .pkgdef). Le fichier pkgdef doit contenir ces informations :
[$RootKey$\OpenFolder\Settings\VSWorkspaceSettings\[settings-name]] @="$PackageFolder$\[settings-file-name].json"Échantillon:
[$RootKey$\OpenFolder\Settings\VSWorkspaceSettings\MockLanguageExtension] @="$PackageFolder$\MockLanguageExtensionSettings.json"Cliquez avec le bouton droit sur le fichier .pkgdef et sélectionnez Propriétés. Modifiez l'action Build en Content et la propriété Include in VSIX à true.
Ouvrez le fichier source.extension.vsixmanifest et ajoutez une ressource sous l’onglet Asset :
de vspackage- Type : Microsoft.VisualStudio.VsPackage
- Source : Fichier sur le système de fichiers
- Chemin d’accès : [Chemin d’accès à votre fichier .pkgdef]
Modification des paramètres par l’utilisateur pour un espace de travail
L’utilisateur ouvre un espace de travail contenant des fichiers que votre serveur possède.
L’utilisateur ajoute un fichier dans le dossier .vs appelé VSWorkspaceSettings.json.
L’utilisateur ajoute une ligne au fichier VSWorkspaceSettings.json pour un paramètre fourni par le serveur. Par exemple:
{ "foo.maxNumberOfProblems": 10 }
Activer le suivi des diagnostics
Le suivi des diagnostics peut être activé afin de générer tous les messages entre le client et le serveur, ce qui peut être utile pour déboguer des problèmes. Pour activer le suivi des diagnostics, procédez comme suit :
- Ouvrez ou créez le fichier de paramètres de l’espace de travail VSWorkspaceSettings.json (voir « Modification des paramètres par l’utilisateur pour un espace de travail »).
- Ajoutez la ligne suivante dans le fichier json des paramètres :
{
"foo.trace.server": "Off"
}
Il existe trois valeurs possibles pour la verbosité de trace :
- « Désactivé » : le suivi s’est complètement désactivé
- « Messages » : le suivi activé, mais seul le nom de la méthode et l’ID de réponse sont suivis.
- « Détaillé » : le traçage est activé ; le message RPC entier est traqué.
Lorsque le suivi est activé, le contenu est écrit dans un fichier dans le répertoire %temp%\VisualStudio\LSP. Le journal suit le format de nommage [LanguageClientName]-[Datetime Stamp].log. Actuellement, le suivi ne peut être activé que pour les scénarios de dossiers ouverts. L’ouverture d’un fichier unique pour activer un serveur de langage ne prend pas en charge le suivi des diagnostics.
Messages personnalisés
Il existe des API en place pour faciliter le passage de messages vers et la réception de messages à partir du serveur de langue qui ne font pas partie du protocole Standard Language Server Protocol. Pour gérer les messages personnalisés, implémentez interface ILanguageClientCustomMessage2 dans votre classe cliente de langue. bibliothèque vs-StreamJsonRpc est utilisée pour transmettre des messages personnalisés entre votre client de langue et votre serveur de langue. Étant donné que votre extension cliente de langage LSP est tout comme n’importe quelle autre extension Visual Studio, vous pouvez décider d’ajouter des fonctionnalités supplémentaires (qui ne sont pas prises en charge par le LSP) à Visual Studio (à l’aide d’autres API Visual Studio) dans votre extension via des messages personnalisés.
Recevoir des messages personnalisés
Pour recevoir des messages personnalisés du serveur de langue, implémentez la propriété [CustomMessageTarget]((/dotnet/api/microsoft.visualstudio.languageserver.client.ilanguageclientcustommessage.custommessagetarget) sur ILanguageClientCustomMessage2 et renvoyez un objet qui sait gérer vos messages personnalisés. Exemple ci-dessous :
(/dotnet/api/microsoft.visualstudio.languageserver.client.ilanguageclientcustommessage.custommessagetarget) propriété sur ILanguageClientCustomMessage2 et retourner un objet capable de gérer vos messages personnalisés. Exemple ci-dessous :
internal class MockCustomLanguageClient : MockLanguageClient, ILanguageClientCustomMessage2
{
private JsonRpc customMessageRpc;
public MockCustomLanguageClient() : base()
{
CustomMessageTarget = new CustomTarget();
}
public object CustomMessageTarget
{
get;
set;
}
public class CustomTarget
{
public void OnCustomNotification(JToken arg)
{
// Provide logic on what happens OnCustomNotification is called from the language server
}
public string OnCustomRequest(string test)
{
// Provide logic on what happens OnCustomRequest is called from the language server
}
}
}
Envoyer des messages personnalisés
Pour envoyer des messages personnalisés au serveur de langage, implémentez la méthode AttachForCustomMessageAsync sur ILanguageClientCustomMessage2. Cette méthode est appelée lorsque votre serveur de langue est démarré et prêt à recevoir des messages. Un objet JsonRpc est passé en tant que paramètre, que vous pouvez ensuite conserver pour envoyer des messages au serveur de langage à l’aide de VS-StreamJsonRpc API. Exemple ci-dessous :
internal class MockCustomLanguageClient : MockLanguageClient, ILanguageClientCustomMessage2
{
private JsonRpc customMessageRpc;
public MockCustomLanguageClient() : base()
{
CustomMessageTarget = new CustomTarget();
}
public async Task AttachForCustomMessageAsync(JsonRpc rpc)
{
await Task.Yield();
this.customMessageRpc = rpc;
}
public async Task SendServerCustomNotification(object arg)
{
await this.customMessageRpc.NotifyWithParameterObjectAsync("OnCustomNotification", arg);
}
public async Task<string> SendServerCustomMessage(string test)
{
return await this.customMessageRpc.InvokeAsync<string>("OnCustomRequest", test);
}
}
Couche intermédiaire
Parfois, un développeur d’extensions peut souhaiter intercepter les messages LSP envoyés au serveur de langue et les recevoir. Par exemple, un développeur d’extensions peut vouloir modifier le paramètre de message envoyé pour un message LSP particulier, ou modifier les résultats retournés par le serveur de langue pour une fonctionnalité LSP (par exemple des achèvements). Quand cela est nécessaire, les développeurs d’extensions peuvent utiliser l’API MiddleLayer pour intercepter les messages LSP.
Pour intercepter un message particulier, créez une classe qui implémente l’interface ILanguageClientMiddleLayer. Ensuite, implémentez l’interface ILanguageClientCustomMessage2 dans votre classe cliente de langue et retournez une instance de votre objet dans la propriété MiddleLayer. Exemple ci-dessous :
public class MockLanguageClient : ILanguageClient, ILanguageClientCustomMessage2
{
public object MiddleLayer => DiagnosticsFilterMiddleLayer.Instance;
private class DiagnosticsFilterMiddleLayer : ILanguageClientMiddleLayer
{
internal readonly static DiagnosticsFilterMiddleLayer Instance = new DiagnosticsFilterMiddleLayer();
private DiagnosticsFilterMiddleLayer() { }
public bool CanHandle(string methodName)
{
return methodName == "textDocument/publishDiagnostics";
}
public async Task HandleNotificationAsync(string methodName, JToken methodParam, Func<JToken, Task> sendNotification)
{
if (methodName == "textDocument/publishDiagnostics")
{
var diagnosticsToFilter = (JArray)methodParam["diagnostics"];
// ony show diagnostics of severity 1 (error)
methodParam["diagnostics"] = new JArray(diagnosticsToFilter.Where(diagnostic => diagnostic.Value<int?>("severity") == 1));
}
await sendNotification(methodParam);
}
public async Task<JToken> HandleRequestAsync(string methodName, JToken methodParam, Func<JToken, Task<JToken>> sendRequest)
{
return await sendRequest(methodParam);
}
}
}
La fonctionnalité de couche intermédiaire est toujours en cours de développement et n’est pas encore complète.
Exemple d’extension de serveur de langage LSP
Pour afficher le code source d’un exemple d’extension à l’aide de l’API cliente LSP dans Visual Studio, consultez l’exemple VSSDK-Extensibility-Samples LSP.
FAQ
j’aimerais créer un système de projet personnalisé pour compléter mon serveur de langage LSP afin de fournir une prise en charge des fonctionnalités plus riche dans Visual Studio, comment procéder ?
La prise en charge des serveurs de langage basés sur LSP dans Visual Studio s’appuie sur la fonctionnalité ouvrir le dossier et est conçue pour ne pas nécessiter de système de projet personnalisé. Vous pouvez créer votre propre système de projet personnalisé en suivant les instructions ici, mais certaines fonctionnalités, telles que les paramètres, peuvent ne pas fonctionner. La logique d’initialisation par défaut pour les serveurs de langage LSP consiste à transmettre l’emplacement du dossier racine du dossier en cours d’ouverture. Par conséquent, si vous utilisez un système de projet personnalisé, vous devrez peut-être fournir une logique personnalisée pendant l’initialisation pour vous assurer que votre serveur de langue peut démarrer correctement.
Comment ajouter la prise en charge du débogueur ?
Nous fournirons la prise en charge du protocole de débogage commun dans une prochaine version.
S’il existe déjà un service de langage pris en charge par VS (par exemple, JavaScript), puis-je toujours installer une extension de serveur de langage LSP qui offre des fonctionnalités supplémentaires (telles que le linting) ?
Oui, mais toutes les fonctionnalités ne fonctionneront pas correctement. L’objectif ultime des extensions de serveur de langage LSP est d’activer les services linguistiques non pris en charge en mode natif par Visual Studio. Vous pouvez créer des extensions qui offrent une prise en charge supplémentaire à l’aide de serveurs de langage LSP, mais certaines fonctionnalités (telles qu’IntelliSense) ne sont pas une expérience fluide. En général, il est conseillé d’utiliser les extensions de serveur de langage LSP pour fournir de nouvelles expériences linguistiques, sans étendre celles existantes.
Où publier mon serveur de langage LSP terminé VSIX ?
Consultez les instructions de la Place de marché ici.