Optimizing the .NET Framework Deployment Experience for Users and Developers
Rapid development has been one of the enduring themes behind the design of the .NET Framework. We know that authoring application installers is particularly difficult and could be improved. The following post is by Richard Lander from the program management team on the Common Language Runtime. He explains our motivations for introducing a new model for deploying the .NET Framework as seen in the Windows 8 Developer Preview and updated in the Windows 8 Consumer Preview. – Brandon
Everyone knows that it’s all about the apps. I can think back to the early 1990s, when I was using both WordPerfect 5.1 and Microsoft Word 2.0c, both awesome desktop apps for the time, on Windows. Fast forward to the 2000s, and you’ll find many developers using the .NET Framework to build both desktop apps and websites and services. For many developers, the .NET Framework is the only Windows development platform that they know and love.
In this blog post, I’ll discuss how Windows 8 significantly improves the end-user experience of using .NET Framework apps, when the app depends on a .NET Framework version that isn’t a built-in component of a particular version of Windows. We will look at the integrated experience that Windows 8 provides to run apps built for the .NET Framework 3.5 and earlier versions.
User Experience on Windows 7 (and earlier versions)
While developers have created huge numbers of great apps with the .NET Framework, they don’t always deploy the required .NET Framework version as part of the installation experience, and sometimes leave that step to end-users. In that case, end-users have to go out and download the .NET Framework themselves. In the early years of the .NET Framework, end-users had just one or two versions to choose from, and could manage this task. By 2012, there are quite a few .NET Framework versions that have been shipped, and knowing which version is the right or best one to install to get an app to run presents a little too much of a guessing-game for most end-users.
On Windows 7 (and earlier Windows versions), we provide an easier experience for Windows users who attempt to run .NET Framework apps but do not have the correct version of the .NET Framework installed. This experience is oriented around a simple error dialog, which takes users directly to the download page for the required .NET Framework version.
Error dialog for missing .NET Framework versions in Windows 7
All in all, this is a reasonable experience, but when you think about it in broader terms, the dialog and web-page are simply guiding the users through a manual, if well-orchestrated, .NET Framework installation process. In the planning of Windows 8, we decided that this experience wasn’t good enough for our customers.
Looking at the Numbers
The dialog above simply directs end-users to a set of web-pages, so we have access to data that gives us a partial view into which versions of the .NET Framework are actively in use, and which versions end-users most often need to (sadly) deploy themselves. The following chart provides a high-level view of the data coming in through our existing dialog.
.NET Framework versions missing on Windows XP, Windows Vista, and Windows 7
This chart is open to wild interpretation unless you have the right context. You may have noticed two major trends with the .NET Framework and Windows over the last decade:
- The .NET Framework is built into Windows, starting with later Windows XP SKUs (for example, the Media Center Edition) and then in earnest with Windows Server 2003 and Windows Vista.
- Each Windows version includes only one version of the .NET Framework.
Re-interpreting the chart with this information in mind, one would guess that:
- A significant percentage of the .NET Framework 2.0 traffic is coming from Windows XP, which generally did not ship with a .NET Framework version, whereas both Windows Vista and Windows 7 can run .NET Framework 2.0 and 3.5 apps.
- The .NET Framework 4 is a significant part of the chart above, since no released Windows version has included that version.
The chart below demonstrates the theory that nearly all the missing .NET Framework 2.0 installations are specific to Windows XP.
End-users missing .NET Framework 2.0 (or 3.5), by Windows OS version
User Experience on Windows 8
The Windows 8 Consumer Preview includes .NET Framework 4.5 Beta, and will include .NET Framework 4.5 RTM when the new OS ships. Note that the .NET Framework 4.5 can be thought of as including the .NET Framework 4, because the .NET Framework 4 does not need to be additionally installed. That leaves end-users in the position of needing to deploy the .NET Framework 3.5 onto their Windows 8 machines, to run .NET Framework 2.0, 3.0, and 3.5 desktop apps, if we continued with the Windows 7 user experience. Given the data from Windows XP and the fact that the .NET Framework 3.5 is included in Windows Vista and Windows 7, one can assume that there are a great number of .NET Framework 3.5 apps that Windows 8 customers will want to run on their PCs.
Unlike Windows 7, Windows 8 automatically downloads and installs the .NET Framework 3.5 from Windows Update. There are no links to follow, no risk of missteps by customers who are not sure which .NET Framework versions to download and install from MSDN. The whole experience requires just a few simple clicks, and then you are done.
The new experience centers around a new dialog box, which users will typically see when they attempt to install a .NET Framework 3.5 (or earlier version) app, or run the app, if it doesn’t have an installer. We released this new experience with the Windows Developer Preview at the Microsoft BUILD conference, and have updated it for the Windows 8 Consumer Preview. See the latest user experience in the image below.
The .NET Framework 3.5 deployment experience in the Windows 8 Consumer Preview build
We’ve seen significant uptake of this new experience. With the Windows Developer Preview, we saw users opt to download the .NET Framework 3.5 on ~25% of machines via the new experience.
Additionally, the .NET Framework 3.5 can be installed via the existing control panel experience.
For more information about these user experiences, see Installing the .NET Framework 3.5 on Windows 8 Consumer Preview in the MSDN Library.
Developers have built many apps with the .NET Framework platform. On Windows 8, developers can count on the .NET Framework 4.5 being built into the operating system, and .NET Framework 3.5 being easily accessible via Windows Update. With both versions at hand, end-users will have a great experience running .NET Framework apps on Windows 8.
Do you like this experience? Do you see it as an improvement? Is there anything about it that you would change?