Visual Studio 2010 MEF vs MPF?

1.4k views Asked by At

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?

3

There are 3 answers

1
Ray On BEST ANSWER

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

1
Sam Harwell On

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.

2
Cameron On

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.)