We continue to invest in the VisualStudio.Extensibility SDK to allow developers like you to create extensions that run faster and smoother than ever before! VisualStudio.Extensibility helps you build extensions that run outside the main Visual Studio IDE process for improved performance and reliability, and that can be installed without the need to restart Visual Studio. Additional benefits include a sleek and intuitive .NET 8-based API and comprehensive, well-maintained documentation to help you develop amazing extensions faster than ever before.

In the recent releases of Visual Studio, we’ve focused on documenting features that are polished for GA, so we haven’t blogged often about features available only in the preview channel. However, some features are worthy of early announcement to gather feedback so we can iterate earlier and make the experience better. Today, we’re writing about one such feature – managing the .NET runtime versions, which is available for you to try out in 17.14 Preview 1.

A key benefit of VisualStudio.Extensibility is that extensions can run out of process on .NET 8, giving you access to a modern, more performant runtime. However, .NET has some fundamental differences from .NET Framework (netfx): each version of the runtime can run side by side and each version of the runtime goes out of support faster than netfx. A new version of .NET comes out every year, with odd number releases receiving 18 months of support, and even number releases receiving 36 months (see here for the official .NET support policy). Thus, for extensions running out of process on VisualStudio.Extensibility, we must roll forward our version of .NET every so often, even after Visual Studio 2022 is past active development and goes into servicing. To get more details on Visual Studio’s support policy, please see here.

In 17.14 preview 1, we are introducing the experience that extension developers and consumers can expect when .NET runtime versions roll forward. The following diagram provides a sample timeline of what you can expect for VisualStudio.Extensibility extensions in VS 2022 in the coming years with respect to .NET runtime versions:

Extension consumers should not expect major or intrusive changes to their workflow when .NET runtime versions are rolled forward. Visual Studio will continue to load their VisualStudio.Extensibility extensions, even if these extensions do not specify that they target the latest supported version of .NET. Let’s wind back time and suppose VisualStudio.Extensibility extensions started running on the .NET 6 runtime. With .NET 6 having just reached its end of life, Visual Studio will now load VisualStudio.Extensibility extensions on .NET 8 runtime, even if the extension did not specify that it supports .NET 8. The following screenshot displays the information (icon) displayed when Visual Studio loads an extension that does not specify it supports the installed .NET runtime. When .NET 8 reaches end-of-life, users can expect a similar transition from .NET 8 to .NET 10.

For extension developers, you will have an opportunity to try loading your extensions in the new runtime version before the current runtime goes out of support. The following screenshot displays the new F5 debug experience when a new .NET runtime version is available.

For more information on how to configure your extension to run against different runtimes, please see our official documentation on the subject here.

We understand that this model of updating the runtime even when Visual Studio 2022 goes out of active development deviates from how extensions are typically maintained in the in-proc, VSSDK model. For developers familiar with .NET, each version brings about breaking changes, although they are often scoped and announced well in advance. As with most .NET applications, the majority of extensions do not need to be rewritten or updated to target the latest .NET runtime version. If you as extension developers do not want to take on the additional burden of considering .NET runtime version compatibility, you can also choose to run their VisualStudio.Extensibility extension in the main devenv.exe process against the .NET Framework runtime. However, in doing so you would lose the ability to install your extensions without restarting Visual Studio, since the extensions are no longer run in isolation.

This is a big shift, so we anticipate a lot of questions around this. We urge you to use our GitHub repo to file issues or sound off your concerns in this Developer Community feedback ticket if you have questions or concerns regarding this change.

We want to hear from you!

The time and effort you’ve spent reporting issues and sharing suggestions so far has been instrumental in shaping VisualStudio.Extensibility. We need your help as we continue to develop VisualStudio.Extensibility! Please try out the features and APIs announced and let us know what you think. Check out the docs, browse the code samples, and build your first extension. You can send feedback and report issues through our issue tracker.

To request features, look at Developer Community to see if someone else made a similar request first. Create a new one if you can’t find a similar request. By checking for similar requests and upvoting and commenting on them, you help us better prioritize requests. Give VisualStudio.Extensibility a try today and share your thoughts with us!

We appreciate the time you’ve spent reporting issues/suggestions and hope you continue to give us feedback when using Visual Studio on what you like and what we can improve. Your feedback is critical to help us make Visual Studio the best tool it can be! You can share feedback with us via Developer Community: report any bugs or issues via report a problem and share your suggestions for new features or improvements to existing ones.

Stay connected with the Visual Studio team by following us on YouTube, Twitter, LinkedIn, Twitch and on Microsoft Learn.