Optimizing the .NET Framework Deployment Experience for Users and Developers

Optimizing the .NET Framework Deployment Experience for Users and Developers

Rate This
  • Comments 11

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.

.NET Framework missing error dialog

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.

Chart of missing .NET version distribution

.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:

  1. 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.
  2. Each Windows version includes only one version of the .NET Framework.

Re-interpreting the chart with this information in mind, one would guess that:

  1. 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.
  2. 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.

Chart of OS versions missing .NET 2.0

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.

.NET 3.5 deployment experience with Windows 8 Consumer Preview

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.

.NET 3.5 installation via Windows control panel

For more information about these user experiences, see Installing the .NET Framework 3.5 on Windows 8 Consumer Preview in the MSDN Library.

In Closing

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?

Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post
  • About the .NET Framework 3.5 deployment experience in the Windows 8 Consumer Preview, so there are two ways how to install it. I have a concern about internet availability and speed/bandwidth. It seems in the first way, it requires internet to download it, while in the second way it doesn't require internet to install it (since I assumes it's built-in in Windows 8 installer).

    So my question: why not prefer the second approach for installing it, by assuming that the internet is not available?

  • @Maximilian: Actually, unfortunately, the second approach does exactly the same thing. If you want to install from media, as far as I know you have to use DISM from the commandline manually:

    dism.exe /online /enable-feature /featurename:NetFX3 /Source:x:\sources\sxs /limitaccess

    See social.msdn.microsoft.com/.../ac0fb1cd-6a81-4c5d-bffd-5efd62374d52

  • @Simon -- That's correct, on all accounts.

    I should have clarified that both approaches require access to WU. Once installed, you can disable and then re-enable the feature, and no additional access to WU will be required.

    @Maximilian -- Installation of .NET 3.5 over the wire is a one-time event. On slower connections, the experience may not be fast, but it is also just once per machine.

  • @Simon: Thanks for the info.

    @Richard: As some people raising about this concern here: social.msdn.microsoft.com/.../a6f521a5-8a1d-428d-8ce9-7fccf627784c, is there any particular reason why .NET FX 3.5.1 has to be downloaded from the internet instead of shipped in Windows 8 installer/media? Sometimes internet is not available at all on the clients or internet is behind an authenticated proxy (HTTP 407: requires credentials to be entered).

  • I agree with @Maximilian.

    Given the number of apps that are out there that use/need the .NET 3.5 Framework, why not pre-install it, or include it with the Windows 8 media? If you want to give the customers the best experience, then not having to install the framework to run their existing apps is surely better than prompting them to install it?

    Even if it is a "one-time event", it still upsets/interrupts the users workflow/experience.

    How many administrators/support teams are going to have to install it for new images, or configuring new laptops/PC's? I think they would appreciate one less step!

  • What is the reason behind the decision to not just include .net framework 3.5 in the Windows 8 distro? On the surface that seems like the best way to handle this issue. Windows isn't Linux; I wouldn't think someone installing Windows 8 would care that there's an extra ~50MB of DLL's on their machine.

  • Also totally agree with @Maximilian.

    @Richard:

    We are a lage ISV with an installation base ~400,000 PCs and have currently 3.5 applications in our portfolio. Until know we deploy .NET for ourselves, but it's best if the needed .NET runtime version is contained in Windows itself (e.g. Win7). Our customers have a large amount of PCs which cannot be connected to Windows Update/Internet (e.g. due to security reasons). So we still need a solution to deploy 3.5 for ouselves (BTW: we are interested in the reason why 3.5 isn't included in Win8 as well).

    Other question: What will happen with SQL 2008 R2 where .NET 3.5 is part of the installation? Does 3.5 get downloaded at runtime of SQL or how does the experience look like?

  • The new experience is definitely a huge step backward, because it no longer tells me *which app* has the problem. "An app on my PC"? Could you possibly be any *less* specific? Why should I care about some unspecified app? There are way more preinstalled apps than I'm ever going to use, so the odds of some random app actually being relevant to me are awfully low.

    Windows 8 has shown me this message several times, at random intervals. It's never in response to anything as obvious as, say, me trying to launch a particular app. It just happens, completely unprovoked. It doesn't even say whether it found the problem because it tried to launch an app that needed 3.5, or just because it happened to notice that the app was there (without me even trying to run it). The dialog is happy to tell me more about the .NET Framework 3.5, but it refuses to tell me about why I'm seeing the dialog in the first place.

    So I do the same thing I always do in response to the "Application X was blocked by the Windows Firewall" dialog: I say, "well, if it can't explain *why* it wants to (open a listening socket | install another .NET Framework), then quit bugging me." And I click "Keep blocking" / "Skip this installation".

    I'm surely not the only one who would have this reaction. The default answer to any dialog box is "Cancel, things are already working and I want them to keep working, make this interruption go away so I can get some work done." And the less you bother to explain what's going on, the stronger this reaction is.

    Now, if you could actually be bothered to tell me *which* app has the problem, then I could actually make an informed decision ("yes, I want my RSS reader to work", or whatever it might be), instead of being forced into a blind, knee-jerk "don't bother me, let things keep working" reaction.

    I'll also note that I haven't seen a single problem result from selecting "Don't install .NET 3.5" (apart from getting prompted again at random intervals), so it appears that my knee-jerk reaction is quite successful at keeping my computer working properly.

  • We recognize that there’s an important set of users that need .NET 3.5 on Windows 8 Customer Preview and that will not be able to access Windows Update as they are behind corporate firewalls. For these users we recommend that their IT department distribute a version of Windows 8 that includes .NET 3.5 along with the other changes they make to the OS before distributing it.

    This can be done with the DISM image manipulation tool (following the instructions at technet.microsoft.com/.../hh824822.aspx). DISM is shipped with Windows 8 and as part of the Assessment and Deployment Kit (ADK) which can be download here - www.microsoft.com/.../details.aspx

  • DISM doesn't solve the deployment problem in all cases, because it seems to need Win8 installation media. Since many boxes are OS preinstalled, many customers don't have access to the installation discs, sometimes they even don't have recovery discs.

    Often they don't have access to Windows Update due to several reasons. Not all users have access to WU and the installation medias. How will it be possible to help those people?

    Could you please describe the way how SQL 2008 R2 gets installed while this installation includes .NET 3.5 as well?

  • Our installer is nice enough to auto-download .NET Framework.

    We also ship a "fat" installer for people who know or can guess that component downloads will fail. The fat installer has everything inside itself.

Page 1 of 1 (11 items)