News

Plugged in to Visual Studio 2010

What does the new .NET extensibility model mean for your existing add-ins?

With powerful advances in recent years -- the Visual Studio 2005 automation model and the Visual Studio 2008 Shell -- Microsoft has increased support for customization of its integrated development environment by offering developers broader extensibility. The .NET extensibility model in Visual Studio 2010 takes it a step further.

The code editor and shell, rebuilt using managed code, enable new extensibility based on the Windows Presentation Foundation (WPF) graphics subsystem and extensible objects from the Managed Extensibility Framework (MEF) libraries, on which it's built. Part of the Microsoft .NET Framework 4 and Silverlight 4, MEF lets developers build tools around extension points -- content types, classification types, drop handlers, tags, adornments, margins/scrolling and IntelliSense -- using MEF components (parts), without implementing a package.

PreEmptive Solutions LLC, provider of the .NET obfuscator called Dotfuscator and related services in Visual Studio 2010, used the new extensibility framework to "mash up" usage data generated from its Runtime Intelligence Service with test data inside of the Visual Studio 2010 Ultimate Architect Explorer.

"We took something Microsoft had already done -- they color-coded the nodes in Architect Explorer to show code coverage -- [and] we folded in the usage data from Runtime Intelligence to change the size of the node, so you saw an immediate heat-map gap between code coverage and actual usage," explains Sebastian Holst, chief marketing officer at PreEmptive Solutions. He says the integration points in 2010 are very exciting for developers.

VSIX Files
Visual Studio 2010 also introduces VSIX deployment, a container model for extensions that's based on the Open Packaging Convention (OPC). OPC is used in the Microsoft Office System Open XML specification, which is supported in Office 2007 apps and other Microsoft software. It stores the extension and metadata about the extension -- including manifest and payload -- in a standard .ZIP file.

VSIX is part of the new Extension Manager in Visual Studio 2010 that lets developers manage extensions and share code templates, for example, in the Visual Studio Gallery from a menu within Visual Studio 2010. The Extension Manager supports MEF components, VSPackages, project templates and item templates.

With the new extensibility model, many developers are concerned about having to rewrite existing add-ins as extensions in Visual Studio 2010.

"For Visual Studio 2010, the VSIX format supports VSPackages, MEF Components, Project Templates, Item Templates, Template Wizards, Toolbox Controls and custom extensions, [such as] extensions to a third-party extension," explained Gearard Boland, a developer on Microsoft's Visual Studio Platform team, in response to a similar question on an MSDN forum in February. "It does not support add-ins, Code Snippets and other extension types not listed in the previous point. VSIX also allows you to include assemblies and other resources that your extension requires in their payload and will install them next to your extension component."

Boland continued: "The benefit of switching to a VSIX-supported extension type is that you can take better advantage of the deployment and discoverability aspects that we delivered in Visual Studio 2010 via the Extension Manager and Visual Studio Gallery integration."

Even so, add-ins based on the Automation object model in Visual Studio (EvuDTE) and toolbar (Microsoft.VisualStudio.CommandBars) still work in Visual Studio 2010, but developers may have to employ workarounds. That was the experience of Carlos Quintero, a Microsoft MVP, who updated his MZ-Tools 6.0 add-in to support Visual Studio 2010 RC. "Microsoft finally fixed most of the bugs that I've been reporting in the last months in the WPF-based CommandBars, so add-ins can get loaded in the IDE without crashing," he wrote in his blog in March. "As far as I'm concerned, I was able to work around all the issues that were not fixed -- and won't be in the release to manufacturing."

The updated MZ-Tools is compiled in Visual Studio 2008 against .NET 2.0. Quintero explained: "I have done tests for future versions and it seems to be possible to build a single assembly in the .NET Framework 2.0/CLR 2.0 that targets Visual Studio 2005, 2008 and 2010, using references provided by Visual Studio 2005 (that are also available in next Visual Studio versions), or using Reflection for references whose version changes between IDE versions. (I think that you can use assembly redirections, too.)"

Early adopters of Visual Studio 2010 test builds have also noticed that some adjustments may be needed to successfully migrate add-ins that make use of certain toolbar features. Microsoft has confirmed that developers will need to move to packages for toolbar functionality such as ComboBoxes.

About the Author

Kathleen Richards is the editor of RedDevNews.com and executive editor of Visual Studio Magazine.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube