1

I'm new to Extension writing VS extensions, and finding information on the subject like untangling 3 balls of yarn. I've read quite a bit on the MSDN site, as well done a lot of failed google searches.

My goal is to write a Visual Studio extension (using MEF and MPF) to improve the support for a language, which was created by a 3rd party. The 3rd party already has a VS extension, which supports debug as well as minimal Intellisense, and provides colorization. I don't want to lose their debug support, but I do want to improve every other aspect of the experience.

From my understanding, a given language (content type) can only be supported by one LanguageService and/or set of Editor services through the MEF (colorizing, intellisense, etc). Is this correct? Is it possible to replace their existing Intellisense, and add other features?

R. Olson
  • 25
  • 4
  • Side note: A good .NET decompiler (I like dotPeek) is your best friend when working with VS extensions. A good chunk of VS is written in managed code and can be decompiled to understand some of the more obscure internal workings, not to mention those of the 3rd party you speak of. – Cameron Jul 28 '16 at 21:03

1 Answers1

0

Yes, with a bit of effort you can bypass the registration of their language service and register your own for the same file extensions. The language service is very nearly independent from the debug engine (I say nearly because a couple small things like breakpoint placement at design time passes through some of the language service objects, but it's not very important).

I suggest supplanting their language service with yours completely, which will be a lot simpler than trying to augment theirs without breaking it, especially without having access to their source to make changes.

Most registrations are bound through entries in the registry, e.g. at HKCU\Software\Microsoft\VisualStudio\14.0_Config\. This is not true of MEF components, but MEF components tend to be filtered by content type, which is defined by the language service, so you should be fine as long as you define a different content type in your language service and bind your stuff to that.

You can register your language service for the same file extensions but with a higher priority (via the ProvideEditorExtension attribute on your language service package). Then it's all up to your language service and you don't have to worry about theirs getting in the way (as long as it behaves with content types that are not its own, which it should).

Finally, good luck! Writing a (good) language service from scratch can be a long journey :-)

Cameron
  • 96,106
  • 25
  • 196
  • 225
  • If you have follow-up questions, add a link in the comments here because I don't browse the [vsix] question tag very often ;-) – Cameron Jul 28 '16 at 21:00
  • Thanks @Cameron. So far, it appears that the LanguageService isn't needed at all when using the MEF components. They seem to overlap, and I didn't see any additional features in the LanguageService. Am I correct about that, or did I miss something? This is probably a different question all together, but you've answered my OP. – R. Olson Jul 31 '16 at 20:04
  • Right, MEF is orthogonal to a language service registration, but a lot of services that you want your language service to have are exposed via MEF components (e.g. syntax highlighting, completion). Most MEF components are registered with a specific content type, which is the link between them and the language service (which defines that content type). A language service by itself doesn't do much at all; it's everything else that hooks onto its content type that does the heavy lifting. Sorry for my slow response time! – Cameron Aug 03 '16 at 14:53