Visual Studio 2010 MEF vs MPF?

Question

I'm looking into adding a new programming language to visual sudio 2010 and I'm a little confused on the best approach to take.

I've looked into the MPF and found some examples on how to do syntax highlighting, link up an external parser, etc and it seems pretty straightforward.

Then I read about something called MEF and how it is the new extensibility model for visual studio. I've played about with it and I've got my syntax highlighting working by following some samples. Now, with MEF I'm lost on how I link in my parser for my langauge, as like MPF using ParseSOurce, etc. I'm using ANTLR btw.

Is MEF just for the visual aspects of the editor like highlighting, adornments, etc... or is it possible/recommended to implement language sevices with it?

From what I gather MEF is the new, recommended approach but it seems harder to create a new language than with the regular MPF. Is MPF still a good approach?

Hemato

One of the best ways is by studying how a current project does it. Try taking a look at IronPython and the "Python Tools for Visual Studio" to see how they add support for the python language to VS. – Cottrill

This question is still missing an accepted answer. Did my answer help you or do you need more details? =3 – Spevek

Yikes, I had forgotten about this, it was a while back. Your answer was very helpful thank you and I went the MPF route. – Hemato

Answer 1

MEF (Managed Extensibility Framework) is a general programming approach in .NET to extend programs, like Visual Studio. VS packages / extensions can use the newer VS-MEF classes (contracts) instead of MPF classes. MEF is recognized by classes decorated with [Export] attributes. Generally said, you inherit a specific class like a colorable item and export it to Visual Studio which then looks up all the exports in your MEF package and imports them.

MPF (Managed Package Framework) is like a class system around the older COM wrappers of the non-managed / native VS extension model. You programmatically extend Visual Studio by getting services and implement methods of MPF classes (the MPF classes in turn implement COM-like interfaces of the COM wrappers of VS. For example LanguageService implements IVsLanguageInfo and some other interfaces, but it just simply "collects" methods of those interface which you can then override in your LanguageService implementing class).

If you want to implement a complete programming language, you will combine MPF and MEF. You use MEF for the editor parts like tokenization (which is needed for Syntax highlighting), outlining, brace matching etc. and MPF for the other VS stuff like new tool windows, property pages etc.

Instead of MPF you can also use the older COM wrappers, but the MPF classes already do some COM work for you which you would have to deal with if you choose the COM wrappers.

You can also implement the tokenizer etc. with MPF, but I tried it and find it much more un-intuitive than MEF. If you ask me, it's much harder, and requires more braindamage than MEF, but I have yet to get as far with MEF as I got with MPF.

It's a bit confusing to myself because MSDN mixes up articles of MEF and MPF as I noticed. You need to watch very carefully in which subsection of MSDN you go, you can easily switch from a MEF category to MPF by accident. However, MSDN hints you about what-is-what in some general articles about extending VS, for example here: http://msdn.microsoft.com/en-us/library/cc138569.aspx

Spevek

n.b. regarding "…the MPF classes… implement COM-like interfaces [used with] LanguageService [which] implements IVsLanguageInfo…" As of just recently in vs2017 15.8, the specific use you mentioned has been been enabled via MEF. So silly me, just when I thought they had given up on the (admittedly desperate) task of converting the full legacy VSIX ecosystem to MEF--since to a casual observer it seemed like the effort was "left-for-dead" halfway through--they apparently soldier on. Great answer. – Forborne

Answer 2

I'm currently implementing a language service exclusively with MEF (in VS2013).

Apart from the syntax highlighting (which you could do with an ITagger<ClassificationTag>) and a few other built-in specific-purpose MEF interfaces (e.g. for option pages and various types of intellisense) which you implement as-needed, to do things like background parsing you generally implement IVsTextViewCreationListener and do stuff when a file is opened; alternatively, you could traverse your project hierarchy in the background using your package's Initialize method as the entry point.

Intellisense features, etc. will often require you to respond to a certain command (or monitor keystrokes to know when to pop up a completion list box, for example); you can handle this by implementing IOleCommandTarget and handling the relevant commands (you hook your command handler manually by calling AddCommandFilter on the IVsTextView when a text view is created).

So far I haven't run into anything I can't do via MEF (except for things that can't be done at all); I never really looked into MPF, since I didn't need it.

(Note that at the end of the day, the code tends to resemble a soup of MEF plumbing, VS SDK interfaces and helper classes, and EnvDTE goop.)

Mernamero

For the advanced scenarios that aren't explicitly MEF-sanctioned, here's a trick: once you cast your ITextView up to a IWpfTextView, there's a ton of legacy shims that get anonymously stored in its Properties property, similar to the WPF-style "attached property" usage (i.e. untyped key-value pairs). Most of these aren't available through the MEF declarative attribution model. You can hook the shims you're interested in by subverting them, i.e., swapping a handler of your own into the slot, and then deferring to the (retained) former if/as/when appropriate. – Forborne

@GlennSlayden Good tip. We haven't needed to wrap any of them yet, but getting the ITextDocument from the properties has proven useful. – Mernamero

Answer 3

Use MEF for the features which are exposed through MEF. Other features are handled on a case-by-case basis (ask a specific question if you are having trouble implementing a specific feature). The only thing I still use MPF for is project systems (MPF for Projects, or MPFProj). To handle background parsing, I recommend taking a look at my BackgroundParser implementation (MIT license). It works quite well, although looking back I wish I used the TPL for it and made ReParseImpl return a Task instead of executing synchronously.

• BackgroundParser.cs
• Commit 0d3e55e, showing the introduction and use of BackgroundParser and some required helper classes.

Curlpaper

...alerting you to my comment because I didn't see yours first and subsequently realized you might be interested. – Forborne