2016-07-07 35 views
1

Ich bin neu in Extension schreiben VS Erweiterungen und Informationen über das Thema wie Entwirren 3 Kugeln Garn zu finden. Ich habe ziemlich viel auf der MSDN-Website gelesen, sowie viele fehlgeschlagene Google-Suchen.Doppelte Visual Studio Erweiterung für eine einzige Sprache

Mein Ziel ist es, eine Visual Studio-Erweiterung (mit MEF und MPF) zu schreiben, um die Unterstützung für eine Sprache zu verbessern, die von einer Drittpartei erstellt wurde. Die dritte Partei hat bereits eine VS-Erweiterung, die sowohl Debug als auch minimales Intellisense unterstützt und eine Kolorierung bereitstellt. Ich möchte ihre Debug-Unterstützung nicht verlieren, aber ich möchte jeden anderen Aspekt der Erfahrung verbessern.

Aus meiner Sicht kann eine bestimmte Sprache (Inhaltstyp) nur von einem LanguageService und/oder einer Reihe von Editor-Diensten über das MEF (Colorizing, IntelliSense, usw.) unterstützt werden. Ist das richtig? Ist es möglich, das vorhandene Intellisense zu ersetzen und weitere Funktionen hinzuzufügen?

+0

Seitennotiz: Ein guter .NET Decompiler (ich mag dotPeek) ist dein bester Freund wenn du mit VS Erweiterungen arbeitest. Ein guter Teil von VS ist in verwaltetem Code geschrieben und kann dekompiliert werden, um einige der obskureren internen Abläufe zu verstehen, ganz zu schweigen von denen der dritten Partei, von der Sie sprechen. – Cameron

Antwort

0

Ja, mit ein wenig Aufwand können Sie die Registrierung ihres Sprachdienstes umgehen und eigene für die gleichen Dateierweiterungen registrieren. Der Sprachdienst ist fast unabhängig von der Debug-Engine (ich sage fast, weil ein paar kleine Dinge wie die Breakpoint-Platzierung zur Entwurfszeit einige Sprachdienstobjekte durchläuft, aber das ist nicht sehr wichtig).

Ich schlage vor, ihren Sprachendienst vollständig durch Ihren zu ersetzen, was sehr viel einfacher ist, als zu versuchen, ihre zu erweitern, ohne sie zu brechen, besonders ohne Zugriff auf ihre Quelle, um Änderungen vorzunehmen.

Die meisten Registrierungen sind durch Einträge in der Registrierung gebunden, z. um HKCU\Software\Microsoft\VisualStudio\14.0_Config\. Dies ist nicht wahr MEF-Komponenten, aber MEF-Komponenten neigen dazu, nach Inhaltstyp gefiltert werden, die durch den Sprachdienst definiert ist, so sollten Sie in Ordnung sein, solange Sie einen anderen Inhaltstyp in Ihrem Sprachdienst definieren und binden Sie Sachen dazu.

Sie können Ihren Sprachdienst für die gleichen Dateierweiterungen registrieren, jedoch mit einer höheren Priorität (über das Attribut ProvideEditorExtension in Ihrem Sprachdienstpaket). Dann hängt alles von Ihrem Sprachdienst ab und Sie müssen sich keine Sorgen machen, dass sie in die Quere kommen (solange sie sich mit Inhaltstypen verhält, die nicht ihre eigenen sind, was sie auch tun sollten).

Endlich, viel Glück! Einen (guten) Sprachdienst von Grund auf zu schreiben kann eine lange Reise sein :-)

+0

Wenn Sie Fragen haben, fügen Sie einen Link in den Kommentaren hinzu, da ich das [vixix] Frage-Tag nicht oft durchsuche ;-) – Cameron

+0

Danke @Cameron. Bisher scheint es, dass der LanguageService bei Verwendung der MEF-Komponenten überhaupt nicht benötigt wird. Sie scheinen sich zu überlappen und ich sah keine zusätzlichen Funktionen im LanguageService. Habe ich recht, oder habe ich etwas übersehen? Dies ist wahrscheinlich eine andere Frage alle zusammen, aber Sie haben mein OP beantwortet. –

+0

Rechts, MEF ist orthogonal zu einer Sprachdienst-Registrierung, aber viele Dienste, die Ihr Sprachdienst haben soll, werden über MEF-Komponenten verfügbar gemacht (z. B. Syntaxhervorhebung, Vervollständigung). Die meisten MEF-Komponenten sind mit einem bestimmten Inhaltstyp registriert, der die Verbindung zwischen ihnen und dem Sprachdienst (der diesen Inhaltstyp definiert) darstellt. Ein Sprachdienst allein macht überhaupt nicht viel; es ist alles andere, was an seinem Inhaltstyp hängt, der das schwere Heben tut. Entschuldigung für meine langsame Reaktionszeit! – Cameron