I’ve been “playing around” with VSIP and the Managed Package Framework for a week or so now, with mixed feelings. The API has (what seems to be) an extremely steep learning curve, I’m not a COM or C++ programmer so the API feels fairly alien to me, and I’ve had to go delving through the registry more in the last week than I have in the last few years. On a positive note though I noticed the Xml editor and Xslt debugger for VS 2005 are both written in managed code (with the Xml editor using the MPF). Internal use of stuff by Microsoft generally correlates with better quality so this is encouraging. In the Xml editor implementation surprisingly very few of the classes are sealed, potentially allowing you to “extend” the Xml editor by normal inheritance (altho sealing of classes often occurs later in the development cycle, so some stuff could be sealed up in the RTM that is not now).
Right now I’m wrangling with the CreateLineMarker method if the IVsTextLines interface, and wondering why it always returns a large negative result. Disturbingly a search for CreateLineMarker in Google show a large number of results from pre-marital counselling services. Is my marriage headed for the rocks? Or is it the weblog of Dr Ex (ex for extensibility, not ex as in former) and his post on implementing custom text markers the cause of it all?
Agreed. The docs state that just about everything can be done in managed code that can be done non-managed. Only there doesn’t seem to be a whole heck of a lot available in terms of anything to back that up.
Playing around in there gives you the sense that it’s VERY comprehensive, but really not ready for prime-time managed manipulation – $10 says all of the VSIP partners out there adding their own extensions are doing them in non-managed code. (Case in point: Intellisense, looks like the only way to extend intellisense is via the Babel APIS - no MENTION of the chance to interact with Intellisense via something as simple as the Automation Model (or through any other managed interface))