I am currently in the middle of developing a project system for Boo
http://boo.codehaus.org/ Since VS 2005 I had quite a few run ins with VS extensibility, primarily packages, but as far as project system usually I was able to get away with project flavoring. This is the first time I face creation of a full blown project
system from scratch.
Anyway – to answer your questions:
The project system is supposed to integrate Boo compiler into the VS IDE. Out of the box Boo provides the compiler, interpreter and the target file/tasks compatible with MSBuild. As we decided to use Boo in our development we needed a way to integrate Boo
development in our development process. As our IDE is Visual Studio we need a way to compile/debug Boo in Visual Studio side by side with majority of our code which will remain in C#.
The decision to use MPF was easy – the alternative is to implement all nitty gritty myself. Considering how much ground would have to be covered, I think I would not take this project on without MPF. Without (before) the Boo project system I had to
compile the Boo part of our app separately and maintain the dll dependencies manually
As far as main points – the intended use of the Boo project system is to be used in a standard development process – I should be able to compile/run/debug entire solution with Boo code mixed with code in any other language directly from IDE.
Publish/Deploy from VS is not a concern at this time.
For the pain/concerns, I have two major ones.
First of all the documentation is very poor, I would hazard to say it is virtually nonexistent. For over 600 virtual methods which can be overridden there is a total of may be 30 pages of documentation. Of course you also have comments in the code and comparing
with the MPF predecessor – the base project system, a part of VS2008 SDK, they are much more informative, still, using MPF requires a lot of guessing and stepping through the code. From the MPF integration standpoint my project turned out to be pretty
simple, but this simplicity is based on the knowledge gathered during my 5 years of messing with VS Extensibility. I plan to blog about my experience with MPF in the near future.
A bigger concern is that it is not clear what is the goal of the MPF project? Is it supposed to be a stable API to create project systems? Or it is just a loose collection of code for anybody to play with? Considering the vast area to be covered by the project
system multiplied by wild variety of use cases it is inevitable there will be issues and outright bugs. How fast they will be addressed? And who and how is watching over the project so that fixing one issue does not create a different one. I ran into a small
problem myself and I found a solution good enough for me (see the issue I submitted) but is it good enough for everybody else? The concern here is that a thousand developers will pull MPF in a thousand different directions, as a result when you guys release
a new version of MPF for a new version of VS, it will not be compatible with any of them. So I as well as a thousand of others will have to start over from scratch.
In light of the latter my question is – are any of the native MS Project systems based on MPF? To the best of my knowledge the answer is no. I know for sure that IronPython as well as FSharp are both based on the previous incarnation of MPF –
sort of. But not the latest one.
As to recommending – my recommendation would be stay away from MPF if you can, use project flavoring, or if possible do not touch the project system at all, but if you need to build a project system from scratch I think MPF is the only viable option.
You guys did a great job putting it all together and isolating small guys like myself from the COM hell. Certainly with a project this huge there is always room for making it simpler, better, but we (at least I) are much better with it than without.
P.S. I tried to post a replay via e-mail and it bounced back, so now I do it through the web site. My apologies if you will get it twice