At //build 2016, Microsoft announced the first public preview of a quick way to get Visual Studio “15” Preview. We’ve previously shared posts about what we’re building and why:
In building faster ways of getting VS, we needed to reduce the size of the minimum product, change a bit of the way the IDE itself ran, change the way components are installed on your computer, and reduce the way components can impact your system. In this article, I will share a little about what it took to make this come together. The details are not so much as to communicate final engineering changes, but to share a bit about how we’re building Visual Studio as a product to hopefully better fit your needs.
The “Core Editor” experience
When we looked at the overall makeup of what makes Visual Studio, depending on how you categorize the components they come out something like this:
- The Visual Studio “Application”: 4-6 GB
- Microsoft’s platform SDKs: 12-16 GB
- Runtimes (CLR, uCRT, ASP.NET, etc.): < 1 GB
- Emulators: 4GB (and up)
That’s a very large payload primarily optimized to make editing through ‘F5’ work ‘out of the box for the many platforms that Visual Studio supports. But that’s not necessarily what everyone needed. Many of you requested simple code editing and the ability to work across folders and projects quickly. In response, we invested in the ability to open a folder without the need for projects. In addition, by leveraging our support for TextMate bundles from Visual Studio 2015 Update 1, we’ve worked to give you quick access to code navigation, typing completion, and search without the need for build or full language services. Each of these features requires a relatively small footprint – only a few megabytes. This created an opportunity to have a common experience for all languages and platforms, allowing quick access to code editing and navigation without having to install several gigabytes to get started. We used this experience as our starting point, adding only a few select features that would help you to be productive with your code even without full project system support, including managed and native debugging, Team Explorer for work item management, and source code control support.
By focusing on these core experiences of Visual Studio as an application, we were able to build a coding experience that can be installed in around 325 MB.
Low-impact by design
Visual Studio has historically been optimized for ensuring that the first ‘F5’ experience with any project just works. This means deploying the runtimes and configurations necessary for that experience. That said, one of the things we heard from you was that having Visual Studio installed changes the state of your computer by installing runtimes, adding registry entries, and configuring the system for debugging, in ways that are not easily undone.
We decided we wanted Visual Studio’s core application to work more like an “app”: one folder full of all the application data such that it does not require impact on the system in order to run (at least not by default). To do that, we made changes that reduced the way we impact the system from the application, starting with the registry. The way Visual Studio and its components use the registry in the past can make it difficult to uninstall cleanly. For example, to avoid data loss, Visual Studio left the user data intact in HKEY_CURRENT_USER. In addition, previous versions of Visual Studio wrote a lot of data to the system registry, which is shared among all applications and the operating system. The amount of data we wrote could negatively impact overall system performance.
In this version, we’ve stopped writing component configuration to the system registry. For example, instead of writing to HKEY_LOCAL_MACHINE during installation, we leveraged our existing mechanism for writing configuration using “package-def” (.pkgdef) files. For saving user-specific configuration caches, we’ve stopped using HKEY_CURRENT_USER and moved to storing data in a new file under the AppData folder, moving several megabytes of data out of the system registry. To further ensure that Visual Studio has all that it needs contained in one place, we moved all of the Visual Studio application-specific assemblies out of the GAC, moving all those assemblies into our own application folder. To maintain our performance, we generate native images for the assemblies during install.
All of this enables Visual Studio to be available on the machine without the need for MSI and with very little system impact. As a result, we can start to imagine new, creative ways to deliver the core application to users without impacting the global state of Windows.
Dealing with Singletons
Even with Visual Studio available now as a simple code editor, much of the power associated with Visual Studio lies deeper in the debugging, diagnostic, and project experiences that integrate with runtimes and operating systems in extensive ways. To do this, our acquisition experience still allows customers to acquire the runtimes and configurations that make them productive on the platforms they are working with. These runtimes and SDKs are still mostly installed via MSIs. We’ve chained those experiences into our new installer while keeping the application portion of the experience explicitly separate.
In addition, some of the assets we deploy into MSBuild used to leverage the registry to find Visual Studio. In this case, the low-impact install is technically side-by-side with the “classic” type, MSI-based install experience; therefore, there can be more than one installed at a time. We changed those .targets files to avoid using the registry, instead relying on build variables that can be set by the IDE at build time.
Where do we go from here?
We’re not done yet. Some of the many challenges that remain include associating file extensions and protocols, offering more granular choices at install time, refining our MSBuild and command-line developer experience, fleshing out the extensibility story, and expanding the scope of our supported scenarios beyond C++ Desktop, C# Desktop, Python and Unity Tools.
Please try out the experience today by installing Visual Studio “15” Preview using the lightweight installer.
We’d love to hear from you! The best way send feedback is to click the ‘Send us feedback’ link in the new installer or through Report a Problem in Visual Studio itself. You can also add a new suggestion or comment on an existing suggestion on the Visual Studio UserVoice site.
0 comments