During development of the VSTO 2010 Runtime we added a feature, dubbed Install on Demand, to support VSTO customizations that target both .NET Framework 3.5 and .NET Framework 4 without enforcing installation of both frameworks prior to installation of VSTO 2010. To facilitate this we needed to break the runtime into 3 components as shown in this diagram.
VSTO Loader can be viewed as the native component of the VSTO 2010 Runtime that communicates with Office. It has no managed dependency and is the only component of the VSTO 2010 Runtime that is guaranteed to be “turned on” no matter how the runtime is installed (the different installation scenarios are discussed below). The extensions (Office 3.5 Runtime Extensions and Office 4.0 Runtime Extensions), shown above VSTO Loader, are the components necessary to execute customizations that target the corresponding version of the .Net Framework. The red arrows indicate which .Net Framework version the extensions depend on.
To better understand how the new Install on Demand functionality will affect you and your end users I will explain the impact from the 3 distinct scenarios with which the VSTO 2010 Runtime can be installed.
- Visual Studio 2010
- Office 2010
- VSTO 2010 Runtime redistributable
Because of these different scenarios we could not assume (or enforce a prerequisite) that any particular version of the .NET Framework was installed on an end users machine at the time they install the VSTO 2010 Runtime. To make this clear, imagine you are deploying a customization that targets .Net Framework 3.5 to a customer who has not yet moved to .Net Framework 4. If we were to unconditionally install all 3 components in the diagram above we would be forced to prereq the .Net Framework 4 which would mean your customer would have to install .Net Framework 4 even though your customization would not require it. Similarly, if you were deploying a customization that targets .Net Framework 4 to a customer that has .Net Framework 4 and no .Net Framework 3.5 we would have to prereq .Net Framework 3.5. What we did was to allow the extensions to only be “turned on” once the version of the .NET Framework that they depend on was present. As a result of the Install on Demand design we have made it more flexible for developers and end users to install the VSTO 2010 Runtime “once” and forget about it. No manual configuration of VSTO is required after installing a version of the .Net Framework that “lights up” either of the extensions.
Visual Studio 2010
VSTO 2010 Runtime, as it has been in past Visual Studio releases, is chained in with the Visual Studio 2010 installation. Developers who install Visual Studio 2010 on a machine without .NET Framework 3.5 will have the Office 4.0 Runtime Extensions “turned on” and the Office 3.5 Runtime Extensions “turned off” (but ready to be “turned on” when applicable) as is shown here.
If the developer decides to start creating .Net Framework 3.5 customizations they are going to need to install the .NET Framework 3.5. After the .Net Framework 3.5 installation when the developer launches Visual Studio 2010 they will be able to target .NET Framework 3.5. However, the VSTO 2010 Runtime still does not have the Office 3.5 Runtime Extensions “turned on”. No worries, this will be taken care of for the developer the first time they create a VSTO project that targets .Net Framework 3.5. During this initial project creation you will notice an MSI configuration dialog appear.
When the project is successfully created the VSTO 2010 Runtime will have installed the Office 3.5 Runtime Extensions which will transition the runtime into the following state allowing the project to be F5’d.
If .NET Framework 3.5 was on the box prior to the Visual Studio 2010 installation then the runtime will be installed in its entirety (both Office 3.5 and Office 4.0 Runtime Extensions “turned on”) and no Install on Demand will take place from that point on.
If you weren’t already aware, VSTO 2010 will be included in the Office 2010 installation. This is great news for end users who will not have to install the VSTO 2010 Runtime redistributable to execute customizations that target .Net Framework 3.5. Note that in the Beta and RTM releases of Office 2010 you will NOT get Office 4.0 Runtime Extensions (or the capability for them to be “turned on”). If you are deploying customizations that target .Net Framework 4 and they will run on Office 2010 you will need your users to install the VSTO 2010 Runtime redistributable (and of course before their customization will run they will have to install .Net Framework 4).
End users who install Office 2010 will receive the VSTO runtime and the Office 3.5 Runtime Extensions “turn on” capability. That is, if .NET Framework 3.5 is on the machine then these extensions will be installed and “turned on” otherwise they will be ready to “turn on”.
VSTO 2010 Runtime redistributable
End users who install the redistributable, either through the bootstrapper (setup.exe) or the download center, will receive both extensions and be able to run customizations that target both .Net Framework 3.5 and 4. No matter how the machine is configured, at the time the redistributable is installed, all deployed solutions will be able to run as long as the appropriate target .Net Framework version is present. Note that this is not limited to ClickOnce deployment, custom MSI deployment will also work this way. For customizations deployed via ClickOnce the “turning on” of extensions will occur during the installation process and for MSI deployment on first load of the customization. In both these cases users will see the MSI configuration dialog (shown in the image above) briefly.
In conclusion, Install on Demand coupled with the VSTO 2010 Runtime shipping with Office 2010 simplifies many deployment scenarios. End users of Office 2010 customizations that target .Net Framework 3.5 will never need to manually install the VSTO 2010 Runtime nor know of its existence. Those still using Office2007 or Office 2010 with .Net Framework 4 will have the flexibility to install the VSTO 2010 Runtime without worrying if they have the correct .Net Framework down before doing so.