As we have previously covered, with Visual Studio “15” Microsoft has made it a priority to reduce the start-up time and installation size of the editor. Supporting these developments are changes in how extensions are utilized. Extension writers will need to make some modifications to support this new functionality, as Microsoft’s Tim Sneath explains.
Microsoft faces a dilemma when it comes to Visual Studio extensions. In order to keep them both useful and powerful, they are given access to many of the same Visual Studio APIs used by Microsoft. The downside of this approach is that there is little to stop misbehaving extensions from degrading editor performance. Now with VS15, feedback is given to the user when an extension negatively affects the editor's performance.
During startup of the main editor, when an extension is loading Visual Studio will measure the load time. If it exceeds an internally defined threshold, the user will be notified, and if it continues to take a lengthy load-time the user will be presented with the option to disable it. While using the editor, an extension that negatively affects typing responsiveness will trigger a separate notification to give the user an option for it to be disabled.
Since Microsoft is intent on making it possible to get Visual Studio running as quickly as possible, VS15 makes it very easy to only install the components (web, mobile, etc.) that you plan to use. This leaves the remaining pieces available for future installation when needed. This can affect extensions because their operation may be assuming a given piece of functionality is present. The VSIX manifest for extensions has been modified so that Visual Studio will identify any missing pieces the extension needs and install them automatically. This change is expected to be publicly available in the next preview release of VS15.
Extension writers are also going to benefit from new abilities to compile their extensions into native images at install time for better performance. Extensions also gain the ability to install files in additional locations beyond just the extensions folder. This means things like MSBuild tasks can be installed by an extension.
With all of the new capabilities coming for extensions in VS15, a natural follow up question emerges: will extensions written to take advantage of VS15 be backwards compatible? According to Microsoft’s Justin Clareburt, general compatibility is maintained to VS2012. Left unexplained for now is how the use of specific VS15 functionality will be addressed in prior versions (one imagines it is easy to bypass native image support, but what happens if a VS15 extension attempts to install outside the extension folder on VS2013?)