Microsoft’s refreshed out-of-process extensibility model for Visual Studio – still in preview – now supports publication of extensions in the Marketplace and Language Server Protocol, both key features, yet progress is slow for a project first announced two and half years ago.

Extension support is a critical feature for an IDE, since it enables an ecosystem that builds on the base product. The Visual Studio Marketplace has more than 10,000 add-ons, many of which are extensions.

Visual Studio is the second most popular development environment after VS Code, according to the latest StackOverflow survey, despite being a Windows-only tool. It is also an old product, with a shell built with Windows Presentation Foundation and extensive use of the Managed Extensibility Framework (MEF), which means it is tied to the legacy .NET Framework. Likewise, the existing Visual Studio SDK is tied to this legacy technology.

In September 2021 Microsoft introduced a new extensibility model, called Visual Studio Extensibility. Program manager Leslie Richardson described “the new, out-of-proc extensibility model” which enables more reliable extensions that “won’t cause Visual Studio to hang or crash,” and which can be installed without restarting the IDE.

The new model also supports .NET Core, the modern version of .NET, and via .NET all extensions run on all supported architectures, including ARM64.

This week senior program manager Maia Kelner introduced the latest preview of Visual Studio Extensibility, shipped with Visual Studio 2022 17.9, with new features including custom data visualizers for debugging, Language Server Protocol (LSP) support to make it easier to support programming languages, such as Rust, for which support is not built-in; and standalone VSIX packages for installation, enabling publication in the Visual Studio Marketplace.

These are important features, however, there is no word yet on when the new extensibility model might come out of preview, and developers wishing to migrate also face difficult issues with APIs in the old Visual Studio SDK that have no equivalent in the new model. “Having spent time reviewing which of my existing extensions I could rewrite to use the new APIs, I came to the conclusion that it’s none of them,” said one developer in December last year.

In response, principal software engineer Bertan Aygun said that “While we would love to bring a new SDK that incorporates all existing extensibility areas of Visual Studio, it is not a trivial amount of work to create new APIs that cover the vast reach of VSSDK, are easy to use, and support asynchronous and out of process execution for each feature … Once we release a wider preview of the VisualStudio.Extensibility with support to upload extensions to the public gallery, we will start categorizing APIs between stable/preview state.”

That moment has now passed, though on a quick look we did not see the promised stable/preview indication in the documentation. As a workaround for compatibility issues, Microsoft has come up with a hybrid extension project type, that runs in-process and can use both the new and old extension model side by side.

Another issue is that despite the similar name, Visual Studio and VS Code have completely different architectures, limiting the extent to which code can be shared if extension developers wish to support both products. VS Code was designed from the beginning with extensibility in mind, and this along with cross-platform support is a factor in its popularity.