We’ve listened to feedback over the years, and while each new release brought changes to the setup experience of Visual Studio and related products, none have been more significant than what we’re doing for Visual Studio “15”.

New setup engine

With Visual Studio supporting so many platforms and toolkits, one of the goals for Visual Studio “15” is to provide choice and install just what you need. To make it easier for our partners to author component packages for Visual Studio while making sure you get all the required components, an underlying engine needs to provide granularity and cohesion with dependencies. Existing package managers like NuGet and NPM provided much of the inspiration, and we bolstered dependency resolution with additional flexibility. This means that whatever workloads and components you select, and whatever product languages you choose to install, you should get everything you need and only what you need.

Another goal is to install faster. Along with a ground-up rewrite of the setup engine, we also extended VSIX packages to install the core product and many of its components while still supporting platform-specific functionality we had with Windows Installer packages like creating file associations, shortcuts, and NGEN’ing assemblies. Now we can install Visual Studio “15” faster and with better isolation. Many legacy and some updated components continue to ship Windows Installer packages or black box executables, but this work in progress has already seen a lot of migration to the new format and more will follow. These mostly-extracted installations are isolated and can be updated with less interaction with other products or editions.

Product instances

To support a model with lightweight and isolated installations that do not interfere with other products and editions, we needed a way for all partners to query for products that match some set of requirements, like finding the latest Visual Studio “15” that have C++ compilers installed. Registry queries wouldn’t provide the flexibility required in many scenarios we discussed with partners. So we created the concept of “instances” – basically the root folder of an installation and other information about what was installed in that folder (and outside that folder, for legacy packages). Each instance also has its own private registry so they can be configured independently.

The COM server DLLs that implement this functionality will be installed by the setup engine and available on any systems with at least one instance of a product installed. If CoCreateInstance returns REGDB_E_CLASSNOTREG (0x80040154) or a COMException is thrown in managed code with the same HRESULT, it’s a good bet no instances are installed.

While we are exploring other ways to provide discovery, we recently published a set of NuGet packages for native and managed code for VS15:

• Microsoft.VisualStudio.Setup.Configuration.Native Adds the header location and automatically links the library. You only need to add an #include.
• Microsoft.VisualStudio.Setup.Configuration.Interop Provides embeddable interop types. If the interop types are embedded you do not need to redistribute additional assemblies. Simply instantiate the SetupConfiguration runtime callable wrapper (RCW).

I have posted a simple sample in the gallery for C#, C++, and Visual Basic.

You can query all instances installed by the new setup engine, or get an instance for a specified path or the current process path. Using the information provided (and we will be exposing more as we collect feedback), you can determine what workloads and components are installed, and resolve paths to compilers and other tools.

If, for example, you wanted to check if some component package was installed before attempting to light up a dependent feature in the current instance, you could do something like the following:

[csharp] bool IsInstalled(string component) { if (component == null) { throw new ArgumentNullException(nameof(component)); }

var instance = (ISetupInstance2)new SetupConfiguration().GetInstanceForCurrentPath(); return instance?.Packages?.Any(package => string.Equals(package.Id, component, StringComparison.OrdinalIgnoreCase)); } [/csharp]

We will be publishing more about the updated VSIX extension format, how it supports prior releases, and how to depend on workloads and components for VS15 in future posts. For updated samples, please see https://github.com/microsoft/vs-setup-samples.