Dodawanie rozszerzenia protokołu serwera językowego
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. Dzięki wsparciu dla LSP w Visual Studio dostępna jest trzecia opcja.
Aby zapewnić najlepsze możliwe środowisko użytkownika, rozważ również zaimplementowanie Language Configuration, który zapewnia lokalne przetwarzanie wielu tych samych operacji, i w związku z tym może poprawić wydajność wielu operacji edytora specyficznych dla języka obsługiwanych przez dostawcę LSP.
Protokół serwera językowego
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 |
|---|---|
| zainicjuj | tak |
| Zainicjowany | tak |
| Wyłączenie | tak |
| wyjście | tak |
| $/cancelRequest | tak |
| window/showMessage | tak |
| window/showMessageRequest | tak |
| okno/logMessage | tak |
| telemetria/zdarzenie | |
| klient/zarejestrujFunkcję | |
| klient/anulujRejestracjęZdolności | |
| 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 |
| dokumentTekstowy/zamknięty | tak |
| textDocument/completion | tak |
| zakończenie/rozwiązanie | tak |
| textDocument/hover | tak |
| dokumentTekstowy/pomocPodpisu | 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 | |
| dokumentTekstowy/łączeDokumentu | |
| documentLink/resolve | |
| textDocument/rename | tak |
Rozpocznij
Notatka
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 masz skompilowane 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 uruchomić rozszerzenia LSP, należy wykonać następujące czynności:
Odinstaluj wersję zapoznawczą VSIX protokołu Microsoft Visual Studio Language Server.
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 do pakietu NuGet do najnowszej wersji, która nie jest zapoznawcza, dla pakietów LSP .
Usuń zależność od Microsoft Visual Studio Language Server Protocol Preview VSIX z manifestu 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.
Ponowne kompilowanie i ponowne wdrażanie.
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 programowanie rozszerzeń programu Visual Studio Obciążenie dla wystąpienia programu VS.
Następnie utwórz nowy projekt VSIX, przechodząc do Plik>Nowy Projekt>Visual C#>Rozszerzalności>Projekt VSIX:
Instalacja serwera językowego i środowiska uruchomieniowego
Domyślnie rozszerzenia utworzone do obsługi serwerów językowych opartych na LSP w programie Visual Studio nie zawierają samych serwerów językowych ani środowisk uruchomieniowych potrzebnych do ich uruchomienia. Deweloperzy rozszerzeń są odpowiedzialni za dystrybucję serwerów językowych i środowisk uruchomieniowych potrzebnych. Istnieje kilka sposobów, aby to zrobić:
- Serwery językowe można osadzać w vsIX jako pliki zawartości.
- Utwórz pakiet MSI, aby zainstalować serwer językowy i/lub wymagane środowiska uruchomieniowe.
- Podaj instrukcje na Marketplace informujące użytkowników, jak uzyskać środowisko uruchomieniowe i serwery językowe.
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 Grammars dołącz dowolne pliki *.tmlanguage, *.plist, *.tmthemelub wszystkie *.json, które mają zapewnić dostosowane 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%%ProgramFiles(x86)%\Microsoft Visual Studio\<wersji>\<SKU>\Common7\IDE\CommonExtensions\Microsoft\TextMate\Starterkit\Themesg katalogu.
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 pozycję właściwości . Zmień akcję kompilacji na Zawartość i zmień właściwość Uwzględnij w 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 po prostu nazwą uściślania i może być dowolnym unikatowym ciągiem). Wszystkie pliki gramatyk (.tmlanguage) i plików motywów (.tmtheme) w tym katalogu są traktowane 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:
Notatka
Po wykonaniu poprzednich kroków, jeśli dodasz 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ęzyka łączących się z serwerem językowym opartym na protokole 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ć StartAsync, aby zasygnalizować, że serwer języka powinien zostać uruchomiony, lub można wykonać dodatkową logikę i wywołać StartAsync później. Aby aktywować serwer językowy, w pewnym momencie należy wywołać metodę StartAsync.
ActivateAsync jest metodą, która ostatecznie jest wywoływana 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 do zapisu na serwer i odczytu z serwera. Wszelkie wyjątki zgłoszone w tym miejscu są przechwytywane i wyświetlane użytkownikowi za pośrednictwem komunikatu na pasku 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 MEF (Zarządzany Framework Rozszerzalności) do zarządzania punktami rozszerzalności. Atrybut Export 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 zasób w manifeście VSIX.
Otwórz projektanta manifestu VSIX i przejdź do karty Zasoby:
Kliknij przycisk Nowy, aby utworzyć nowy zasób:
- typ: Microsoft.VisualStudio.MefComponent
- Źródło: projekt w bieżącym rozwiązaniu
- project: [Twój projekt]
Definicja typu zawartości
Obecnie jedynym sposobem ładowania rozszerzenia serwera językowego opartego na LSP jest typ zawartości pliku. Oznacza to, że podczas definiowania klasy klienta języka (która implementuje 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 klasy 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;
}
}
W poprzednim przykładzie jest tworzona definicja typu zawartości dla plików kończących się rozszerzeniem .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 MockLanguageExtensionSettings.json) do projektu zawierającego ustawienia i ich wartości domyślne. Na przykład:
{ "foo.maxNumberOfProblems": -1 }Kliknij prawym przyciskiem myszy plik JSON i wybierz Właściwości. Zmień akcję Build na "Content" (Zawartość), a właściwość "Include in VSIX" (Uwzględnij w VSIX) na true.
Zaimplementuj element ConfigurationSections i zwróć listę prefiksów dla ustawień zdefiniowanych w pliku JSON (w programie Visual Studio Code będzie to odpowiadać nazwie 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"Próbka:
[$RootKey$\OpenFolder\Settings\VSWorkspaceSettings\MockLanguageExtension] @="$PackageFolder$\MockLanguageExtensionSettings.json"Kliknij prawym przyciskiem myszy plik .pkgdef i wybierz pozycję Właściwości. Zmień akcję Build na Content i właściwość Include in VSIX na true.
Otwórz plik source.extension.vsixmanifest i dodaj element zawartości na karcie zasobów:
- Typ: Microsoft.VisualStudio.VsPackage
- Source: 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 VSWorkspaceSettings.json.
Użytkownik dodaje wiersz do pliku VSWorkspaceSettings.json dla ustawienia zapewnianego przez serwer. Na przykład:
{ "foo.maxNumberOfProblems": 10 }
Włącz śledzenie 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 VSWorkspaceSettings.json (zobacz "Edytowanie ustawień użytkownika dla obszaru roboczego").
- 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 metod i identyfikatory 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 stosuje format nazewnictwa [LanguageClientName]-[Datetime Stamp].log. Obecnie śledzenie można włączyć tylko dla scenariuszy otwierania folderów. Otwieranie pojedynczego pliku w celu aktywacji serwera językowego nie oferuje obsługi śledzenia diagnostycznego.
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 jest używana do przesyłania niestandardowych komunikatów między klientem językowym 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ć komunikaty niestandardowe z serwera językowego, zaimplementuj właściwość [CustomMessageTarget]((/dotnet/api/microsoft.visualstudio.languageserver.client.ilanguageclientcustommessage.custommessagetarget) w ILanguageClientCustomMessage2 i zwróć obiekt, który wie, jak obsługiwać komunikaty niestandardowe. Przykład poniżej:
Właściwość (/dotnet/api/microsoft.visualstudio.languageserver.client.ilanguageclientcustommessage.custommessagetarget) w ILanguageClientCustomMessage2 i zwraca obiekt, który wie, jak obsługiwać komunikaty niestandardowe. Przykład poniżej:
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 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ć, aby wysyłać komunikaty do serwera językowego przy użyciu interfejsów API VS-StreamJsonRpc. Przykład poniżej:
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ęzykowego i zwróć instancję obiektu we właściwości MiddleLayer. Przykład poniżej:
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 VSSDK-Extensibility-Samples przykładowy LSP.
FAQ
Chciałbym zbudować niestandardowy system projektu, który uzupełni mój serwer językowy LSP, aby zapewnić bogatsze wsparcie funkcji w Visual Studio. Jak mogę to zrobić?
Obsługa serwerów językowych opartych na LSP w programie Visual Studio opiera się na funkcji otwierania folderu i została zaprojektowana tak, aby nie wymagała niestandardowego systemu projektu. Możesz utworzyć własny niestandardowy system projektów zgodnie z instrukcjami tutaj, 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 dodać obsługę debugera?
Zapewnimy obsługę protokołu wspólnego 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ęzykowego 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 dla Marketplace tutaj .