Dodawanie rozszerzenia Language Server Protocol
Protokół LSP (Language Server Protocol) to wspólny protokół, w postaci RPC JSON w wersji 2.0, używany do udostępniania funkcji usługi językowej różnym edytorom kodu. Korzystając z protokołu, deweloperzy mogą napisać jeden serwer językowy, aby zapewnić funkcje usługi językowej, takie jak IntelliSense, diagnostyka błędów, znajdowanie wszystkich odwołań itd. do różnych edytorów kodu, które obsługują dostawcę LSP. Tradycyjnie usługi językowe w programie Visual Studio można dodawać przy użyciu plików gramatycznych TextMate w celu zapewnienia podstawowych funkcji, takich jak wyróżnianie składni lub pisanie niestandardowych usług językowych korzystających z pełnego zestawu interfejsów API rozszerzalności programu Visual Studio w celu zapewnienia bogatszych danych. W przypadku obsługi programu Visual Studio dla dostawcy LSP dostępna jest trzecia opcja.
Aby zapewnić najlepsze możliwe środowisko użytkownika, rozważ również zaimplementowanie konfiguracji języka, która zapewnia lokalne przetwarzanie wielu tych samych operacji i może w związku z tym poprawić wydajność wielu operacji edytora specyficznych dla języka obsługiwanych przez dostawcę LSP.
Language Server Protocol
W tym artykule opisano sposób tworzenia rozszerzenia programu Visual Studio korzystającego z serwera językowego opartego na programie LSP. Przyjęto założenie, że utworzono już serwer językowy oparty na protokole LSP i chcesz go zintegrować z programem Visual Studio.
Aby zapewnić obsługę w programie Visual Studio, serwery językowe mogą komunikować się z klientem (Visual Studio) za pośrednictwem dowolnego mechanizmu transmisji opartego na strumieniu, na przykład:
- Standardowe strumienie wejściowe/wyjściowe
- Nazwane potoki
- Gniazda (tylko TCP)
Celem dostawcy LSP i jego obsługi w programie Visual Studio jest dołączanie usług językowych, które nie są częścią produktu Visual Studio. Nie jest przeznaczona do rozszerzania istniejących usług językowych (takich jak C#) w programie Visual Studio. Aby rozszerzyć istniejące języki, zapoznaj się z przewodnikiem rozszerzalności usługi językowej (na przykład "Roslyn" .NET Compiler Platform) lub zobacz Rozszerzanie edytora i usług językowych.
Aby uzyskać więcej informacji na temat samego protokołu, zobacz dokumentację tutaj.
Aby uzyskać więcej informacji na temat tworzenia przykładowego serwera językowego lub sposobu integrowania istniejącego serwera językowego z programem Visual Studio Code, zobacz dokumentację tutaj.
Obsługiwane funkcje protokołu Language Server
W poniższych tabelach pokazano, które funkcje LSP są obsługiwane w programie Visual Studio:
| Komunikat | Ma obsługę w programie Visual Studio |
|---|---|
| Zainicjować | tak |
| Zainicjowany | tak |
| shutdown | tak |
| exit | tak |
| $/cancelRequest | tak |
| window/showMessage | tak |
| window/showMessageRequest | tak |
| window/logMessage | tak |
| telemetria/zdarzenie | |
| client/registerCapability | |
| client/unregisterCapability | |
| workspace/didChangeConfiguration | tak |
| workspace/didChangeWatchedFiles | tak |
| obszar roboczy/symbol | tak |
| workspace/executeCommand | tak |
| workspace/applyEdit | tak |
| textDocument/publishDiagnostics | tak |
| textDocument/didOpen | tak |
| textDocument/didChange | tak |
| textDocument/willSave | |
| textDocument/willSaveWaitUntil | |
| textDocument/didSave | tak |
| textDocument/didClose | tak |
| textDocument/completion | tak |
| uzupełnianie/rozwiązywanie problemów | tak |
| textDocument/hover | tak |
| textDocument/signatureHelp | tak |
| textDocument/references | tak |
| textDocument/documentHighlight | tak |
| textDocument/documentSymbol | tak |
| textDocument/formatowanie | tak |
| textDocument/rangeFormatting | tak |
| textDocument/onTypeFormatting | |
| textDocument/definition | tak |
| textDocument/codeAction | tak |
| textDocument/codeLens | |
| codeLens/resolve | |
| textDocument/documentLink | |
| documentLink/resolve | |
| textDocument/rename | tak |
Rozpocznij
Uwaga
Począwszy od programu Visual Studio 2017 w wersji 15.8, obsługa wspólnego protokołu Language Server Protocol jest wbudowana w program Visual Studio. Jeśli utworzono rozszerzenia LSP przy użyciu wersji zapoznawczej wersji VSIX klienta serwera językowego, przestaną działać po uaktualnieniu do wersji 15.8 lub nowszej. Aby ponownie pracować rozszerzenia LSP, należy wykonać następujące czynności:
Odinstaluj plik VSIX protokołu Microsoft Visual Studio Language Server w wersji zapoznawczej.
Począwszy od wersji 15.8, za każdym razem, gdy przeprowadzasz uaktualnienie w programie Visual Studio, wersja zapoznawcza VSIX jest automatycznie wykrywana i usuwana.
Zaktualizuj odwołanie nuget do najnowszej wersji innej niż zapoznawcza dla pakietów LSP.
Usuń zależność z plikiem VSIX protokołu Microsoft Visual Studio Language Server Protocol (wersja zapoznawcza) w manifeście VSIX.
Upewnij się, że plik VSIX określa program Visual Studio 2017 w wersji 15.8 (wersja zapoznawcza 3) jako dolną granicę dla miejsca docelowego instalacji.
Ponownie skompiluj i wdróż.
Tworzenie projektu VSIX
Aby utworzyć rozszerzenie usługi językowej przy użyciu serwera językowego opartego na programie LSP, najpierw upewnij się, że masz zainstalowane obciążenie programistyczne rozszerzenia programu Visual Studio dla wystąpienia programu VS.
Następnie utwórz nowy projekt VSIX, przechodząc do pozycji Plik>nowy projekt Visual C#>Rozszerzalność>VSIX:>
Instalacja serwera językowego i środowiska uruchomieniowego
Domyślnie rozszerzenia utworzone do obsługi serwerów językowych opartych na dostawcy LSP w programie Visual Studio nie zawierają samych serwerów językowych ani środowisk uruchomieniowych potrzebnych do ich wykonania. Deweloperzy rozszerzeń są odpowiedzialni za dystrybucję serwerów językowych i wymaganych środowisk uruchomieniowych. Istnieje kilka sposobów, aby to zrobić:
- Serwery językowe można osadzać w vsIX jako pliki zawartości.
- Utwórz tożsamość usługi zarządzanej w celu zainstalowania serwera językowego i/lub wymaganych środowisk uruchomieniowych.
- Podaj instrukcje dotyczące witryny Marketplace informujące użytkowników o sposobie uzyskiwania środowisk uruchomieniowych i serwerów językowych.
Pliki gramatyczne TextMate
Dostawca LSP nie zawiera specyfikacji dotyczącej sposobu zapewniania kolorowania tekstu dla języków. Aby zapewnić niestandardowe kolorowanie języków w programie Visual Studio, deweloperzy rozszerzeń mogą używać pliku gramatycznego TextMate. Aby dodać niestandardowe pliki gramatyki lub motywu TextMate, wykonaj następujące kroki:
Utwórz folder o nazwie "Gramatyki" wewnątrz rozszerzenia (lub może to być dowolna wybrana nazwa).
W folderze Gramatyka dołącz dowolne pliki *.tmlanguage, *.plist, *.tmtheme lub *.json, które mają zapewnić niestandardowe kolorowanie.
Napiwek
Plik tmtheme definiuje sposób mapowania zakresów na klasyfikacje programu Visual Studio (nazwane klucze kolorów). Aby uzyskać wskazówki, możesz odwołać się do globalnego pliku tmtheme w katalogu %ProgramFiles(x86)%\Microsoft Visual Studio\<version>\<SKU>\Common7\IDE\CommonExtensions\Microsoft\TextMate\Starterkit\Themesg .
Utwórz plik pkgdef i dodaj wiersz podobny do następującego:
[$RootKey$\TextMate\Repositories] "MyLang"="$PackageFolder$\Grammars"Kliknij prawym przyciskiem myszy pliki i wybierz polecenie Właściwości. Zmień akcję Kompilacja na Zawartość i zmień właściwość Include in VSIX na true.
Po wykonaniu poprzednich kroków folder Grammars zostanie dodany do katalogu instalacyjnego pakietu jako źródło repozytorium o nazwie "MyLang" ('MyLang' jest tylko nazwą uściślania i może być dowolnym unikatowym ciągiem). Wszystkie gramatyki (pliki tmlanguage ) i pliki motywu (pliki tmtheme ) w tym katalogu są pobierane jako potencjalne i zastępują wbudowane gramatyki dostarczone z TextMate. Jeśli zadeklarowane rozszerzenia pliku gramatycznego są zgodne z rozszerzeniem otwieranego pliku, program TextMate przejdzie do kroku.
Tworzenie prostego klienta językowego
Interfejs główny — ILanguageClient
Po utworzeniu projektu VSIX dodaj następujące pakiety NuGet do projektu:
Uwaga
Po wykonaniu poprzednich kroków zależność od pakietu NuGet pakiety Newtonsoft.Json i StreamJsonRpc również zostaną dodane do projektu. Nie aktualizuj tych pakietów, chyba że masz pewność, że te nowe wersje zostaną zainstalowane w wersji programu Visual Studio przeznaczonej dla rozszerzenia. Zestawy nie zostaną uwzględnione w systemie VSIX; Zamiast tego zostaną one pobrane z katalogu instalacyjnego programu Visual Studio. Jeśli odwołujesz się do nowszej wersji zestawów niż to, co jest zainstalowane na komputerze użytkownika, rozszerzenie nie będzie działać.
Następnie można utworzyć nową klasę, która implementuje interfejs ILanguageClient , który jest głównym interfejsem wymaganym dla klientów językowych łączących się z serwerem językowym opartym na programie LSP.
Poniżej przedstawiono przykład:
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;
}
}
}
Główne metody, które należy zaimplementować, to OnLoadedAsync i ActivateAsync. OnLoadedAsync jest wywoływana, gdy program Visual Studio załadował rozszerzenie, a serwer językowy jest gotowy do uruchomienia. W tej metodzie można natychmiast wywołać delegata StartAsync , aby zasygnalizować, że serwer językowy powinien zostać uruchomiony. Możesz też wykonać dodatkową logikę i wywołać metodę StartAsync później. Aby aktywować serwer językowy, w pewnym momencie należy wywołać metodę StartAsync.
ActivateAsync to metoda w końcu wywołana przez wywołanie delegata StartAsync . Zawiera logikę uruchamiania serwera językowego i nawiązywania z nim połączenia. Należy zwrócić obiekt połączenia zawierający strumienie zapisu na serwerze i odczyt z serwera. Wszelkie wyjątki zgłoszone w tym miejscu są przechwytywane i wyświetlane użytkownikowi za pośrednictwem komunikatu Paska informacji w programie Visual Studio.
Aktywacja
Po zaimplementowaniu klasy klienta języka należy zdefiniować dla niego dwa atrybuty, aby zdefiniować sposób ich załadowania do programu Visual Studio i aktywowania:
[Export(typeof(ILanguageClient))]
[ContentType("bar")]
MEF
Program Visual Studio używa platformy MEF (Managed Extensibility Framework) do zarządzania punktami rozszerzalności. Atrybut Eksportuj wskazuje programOwi Visual Studio, że ta klasa powinna zostać odebrana jako punkt rozszerzenia i załadowana w odpowiednim czasie.
Aby korzystać z mef, należy również zdefiniować mef jako element zawartości w manifeście VSIX.
Otwórz projektanta manifestu VSIX i przejdź do karty Zasoby :
Kliknij pozycję Nowy , aby utworzyć nowy zasób:
- Typ: Microsoft.VisualStudio.MefComponent
- Źródło: Projekt w bieżącym rozwiązaniu
- Projekt: [Projekt]
Definicja typu zawartości
Obecnie jedynym sposobem ładowania rozszerzenia serwera językowego opartego na dostawcy LSP jest typ zawartości pliku. Oznacza to, że podczas definiowania klasy klienta języka (która implementuje element ILanguageClient), należy zdefiniować typy plików, które po otwarciu spowodują załadowanie rozszerzenia. Jeśli nie są otwierane żadne pliki zgodne ze zdefiniowanym typem zawartości, rozszerzenie nie zostanie załadowane.
Odbywa się to przez zdefiniowanie co najmniej jednej ContentTypeDefinition klasy:
namespace MockLanguageExtension
{
public class BarContentDefinition
{
[Export]
[Name("bar")]
[BaseDefinition(CodeRemoteContentDefinition.CodeRemoteContentTypeName)]
internal static ContentTypeDefinition BarContentTypeDefinition;
[Export]
[FileExtension(".bar")]
[ContentType("bar")]
internal static FileExtensionToContentTypeDefinition BarFileExtensionDefinition;
}
}
W poprzednim przykładzie jest tworzona definicja typu zawartości dla plików kończących się rozszerzeniem pliku bar . Definicja typu zawartości ma nazwę "bar" i musi pochodzić z CodeRemoteContentTypeName.
Po dodaniu definicji typu zawartości można zdefiniować, kiedy załadować rozszerzenie klienta języka w klasie klienta języka:
[ContentType("bar")]
[Export(typeof(ILanguageClient))]
public class BarLanguageClient : ILanguageClient
{
}
Dodanie obsługi serwerów językowych LSP nie wymaga zaimplementowania własnego systemu projektu w programie Visual Studio. Klienci mogą otworzyć pojedynczy plik lub folder w programie Visual Studio, aby rozpocząć korzystanie z usługi językowej. W rzeczywistości obsługa serwerów językowych LSP jest przeznaczona do pracy tylko w scenariuszach otwierania folderu/pliku. Jeśli wdrożono niestandardowy system projektu, niektóre funkcje (takie jak ustawienia) nie będą działać.
Funkcje zaawansowane
Ustawienia
Obsługa niestandardowych ustawień specyficznych dla serwera języka jest dostępna, ale nadal jest w trakcie ulepszania. Ustawienia są specyficzne dla tego, co obsługuje serwer językowy i zwykle kontroluje sposób emitowania danych przez serwer językowy. Na przykład serwer językowy może mieć ustawienie maksymalnej liczby zgłoszonych błędów. Autorzy rozszerzeń definiują wartość domyślną, która może zostać zmieniona przez użytkowników dla określonych projektów.
Wykonaj poniższe kroki, aby dodać obsługę ustawień do rozszerzenia usługi językowej LSP:
Dodaj plik JSON (na przykład MockLanguageExtension Ustawienia.json) do projektu, który zawiera ustawienia i ich wartości domyślne. Na przykład:
{ "foo.maxNumberOfProblems": -1 }Kliknij prawym przyciskiem myszy plik JSON i wybierz polecenie Właściwości. Zmień akcję Kompilacja na "Zawartość" i właściwość "Uwzględnij w vsIX" na true.
Zaimplementuj polecenia ConfigurationSections i zwróć listę prefiksów ustawień zdefiniowanych w pliku JSON (w programie Visual Studio Code jest to mapowane na nazwę sekcji konfiguracji w package.json):
public IEnumerable<string> ConfigurationSections { get { yield return "foo"; } }Dodaj plik pkgdef do projektu (dodaj nowy plik tekstowy i zmień rozszerzenie pliku na pkgdef). Plik pkgdef powinien zawierać następujące informacje:
[$RootKey$\OpenFolder\Settings\VSWorkspaceSettings\[settings-name]] @="$PackageFolder$\[settings-file-name].json"Przykład:
[$RootKey$\OpenFolder\Settings\VSWorkspaceSettings\MockLanguageExtension] @="$PackageFolder$\MockLanguageExtensionSettings.json"Kliknij prawym przyciskiem myszy plik pkgdef i wybierz polecenie Właściwości. Zmień akcję Kompilacja na Zawartość i Właściwość Uwzględnij w VSIX na true.
Otwórz plik source.extension.vsixmanifest i dodaj element zawartości na karcie Zasób:
- Typ: Microsoft.VisualStudio.VsPackage
- Źródło: plik w systemie plików
- Ścieżka: [Ścieżka do pliku pkgdef ]
Edytowanie ustawień dla obszaru roboczego przez użytkownika
Użytkownik otwiera obszar roboczy zawierający pliki, których właścicielem jest serwer.
Użytkownik dodaje plik w folderze .vs o nazwie VSWorkspace Ustawienia.json.
Użytkownik dodaje wiersz do pliku VSWorkspace Ustawienia.json dla ustawienia zapewnianego przez serwer. Na przykład:
{ "foo.maxNumberOfProblems": 10 }
Włączanie śledzenia diagnostyki
Śledzenie diagnostyczne można włączyć w celu wyprowadzenia wszystkich komunikatów między klientem a serwerem, co może być przydatne podczas debugowania problemów. Aby włączyć śledzenie diagnostyczne, wykonaj następujące czynności:
- Otwórz lub utwórz plik ustawień obszaru roboczego VSWorkspace Ustawienia.json (zobacz "Edytowanie ustawień dla obszaru roboczego przez użytkownika").
- Dodaj następujący wiersz w pliku json ustawień:
{
"foo.trace.server": "Off"
}
Istnieją trzy możliwe wartości dla szczegółowości śledzenia:
- "Wyłączone": śledzenie całkowicie wyłączone
- "Komunikaty": śledzenie jest włączone, ale śledzone są tylko nazwy metody i identyfikator odpowiedzi.
- "Pełne": włączone śledzenie; cały komunikat rpc jest śledzony.
Po włączeniu śledzenia zawartość jest zapisywana w pliku w katalogu %temp%\VisualStudio\LSP . Dziennik jest zgodny z formatem nazewnictwa [LanguageClientName]-[Datetime Stamp].log. Obecnie śledzenie można włączyć tylko dla scenariuszy otwierania folderów. Otwieranie pojedynczego pliku w celu aktywowania serwera językowego nie ma obsługi śledzenia diagnostyki.
Komunikaty niestandardowe
Istnieją interfejsy API umożliwiające przekazywanie komunikatów do i odbieranie komunikatów z serwera językowego, które nie są częścią standardowego protokołu Language Server Protocol. Aby obsługiwać komunikaty niestandardowe, zaimplementuj interfejs ILanguageClientCustomMessage2 w klasie klienta języka. Biblioteka VS-StreamJsonRpc służy do przesyłania niestandardowych komunikatów między klientem języka a serwerem językowym. Ponieważ rozszerzenie klienta języka LSP jest tak samo jak każde inne rozszerzenie programu Visual Studio, możesz zdecydować się na dodanie dodatkowych funkcji (które nie są obsługiwane przez dostawcę LSP) do programu Visual Studio (przy użyciu innych interfejsów API programu Visual Studio) w rozszerzeniu za pośrednictwem komunikatów niestandardowych.
Odbieranie niestandardowych komunikatów
Aby odbierać niestandardowe komunikaty z serwera językowego, zaimplementuj właściwość [CustomMessageTarget]((/dotnet/api/microsoft.visualstudio.languageserver.client.ilanguageclientcustommessage.custommessagetarget) na ILanguageClientCustomMessage2 i zwróć obiekt, który wie, jak obsługiwać komunikaty niestandardowe. Na przykład:
(/dotnet/api/microsoft.visualstudio.languageserver.client.ilanguageclientcustommessage.custommessagetarget) we właściwości ILanguageClientCustomMessage2 i zwróć obiekt, który wie, jak obsługiwać komunikaty niestandardowe. Na przykład:
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
}
}
}
Wysyłanie niestandardowych komunikatów
Aby wysyłać niestandardowe komunikaty do serwera językowego, zaimplementuj metodę AttachForCustomMessageAsync w językach ILanguageClientCustomMessage2. Ta metoda jest wywoływana, gdy serwer językowy jest uruchomiony i gotowy do odbierania komunikatów. Obiekt JsonRpc jest przekazywany jako parametr, który można następnie przechowywać w celu wysyłania komunikatów do serwera językowego przy użyciu interfejsów API VS-StreamJsonRpc. Na przykład:
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);
}
}
Warstwa środkowa
Czasami deweloper rozszerzenia może chcieć przechwycić komunikaty LSP wysyłane i odbierane z serwera językowego. Na przykład deweloper rozszerzenia może chcieć zmienić parametr komunikatu wysłany dla określonego komunikatu LSP lub zmodyfikować wyniki zwrócone z serwera językowego dla funkcji LSP (na przykład uzupełniania). W razie potrzeby deweloperzy rozszerzeń mogą przechwytywać komunikaty LSP za pomocą interfejsu API MiddleLayer.
Aby przechwycić określony komunikat, utwórz klasę, która implementuje interfejs ILanguageClientMiddleLayer . Następnie zaimplementuj interfejs ILanguageClientCustomMessage2 w klasie klienta języka i zwróć wystąpienie obiektu we właściwości MiddleLayer . Na przykład:
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);
}
}
}
Funkcja warstwy środkowej jest nadal opracowywana i nie jest jeszcze kompleksowa.
Przykładowe rozszerzenie serwera języka LSP
Aby wyświetlić kod źródłowy przykładowego rozszerzenia przy użyciu interfejsu API klienta LSP w programie Visual Studio, zobacz przykład LSP VSSDK-Extensibility-Samples.
Często zadawane pytania
Chcę utworzyć niestandardowy system projektów, aby uzupełnić serwer językowy LSP, aby zapewnić bogatszą obsługę funkcji w programie Visual Studio, jak to zrobić?
Obsługa serwerów językowych opartych na programie LSP w programie Visual Studio opiera się na funkcji otwierania folderu i jest przeznaczona do nie wymagania niestandardowego systemu projektu. Możesz utworzyć własny niestandardowy system projektów zgodnie z instrukcjami , ale niektóre funkcje, takie jak ustawienia, mogą nie działać. Domyślną logiką inicjowania serwerów języka LSP jest przekazanie lokalizacji folderu głównego aktualnie otwieranego folderu, więc jeśli używasz niestandardowego systemu projektów, może być konieczne podanie logiki niestandardowej podczas inicjowania, aby upewnić się, że serwer językowy może działać prawidłowo.
Jak mogę dodać obsługę debugera?
Będziemy zapewniać obsługę wspólnego protokołu debugowania w przyszłej wersji.
Jeśli jest już zainstalowana obsługiwana usługa językowa programu VS (na przykład JavaScript), czy nadal mogę zainstalować rozszerzenie serwera języka LSP, które oferuje dodatkowe funkcje (takie jak linting)?
Tak, ale nie wszystkie funkcje będą działać prawidłowo. Ostatecznym celem rozszerzeń serwera języka LSP jest włączenie usług językowych, które nie są natywnie obsługiwane przez program Visual Studio. Można tworzyć rozszerzenia, które oferują dodatkową obsługę przy użyciu serwerów językowych LSP, ale niektóre funkcje (takie jak IntelliSense) nie będą bezproblemowe. Ogólnie rzecz biorąc, zaleca się, aby rozszerzenia serwera języka LSP były używane do udostępniania nowych środowisk językowych, a nie rozszerzania istniejących.
Gdzie opublikować ukończony serwer LSP language VSIX?
Zobacz instrukcje dotyczące witryny Marketplace tutaj.