Improvements in .NET Framework Setup for Developers, IT Pros, and Users

Improvements in .NET Framework Setup for Developers, IT Pros, and Users

Rate This
  • Comments 3

The only experience most Microsoft customers have with the .NET Framework is the deployment and installation experience, which is why we spend so much time analyzing opportunities to improve it. For .NET 4.5, our goal was to build a product that was equivalent to a service pack with additional features. Our team studied how other products with similar update goals managed to improve their deployment then we took those best practices and applied them to the .NET Framework 4.5. This is an area where we heavily rely on telemetry data to prioritize areas of improvement, a practice that has led to noticeable change over past releases. In the following article, Nithya Chandrasekaran and Richard Lander, program managers from the .NET setup and CLR teams respectively, describe some of the deployment improvements. --Brandon

In this post, we will look at the changes that we made in .NET Framework 4.5 setup to alleviate pain points that have affected developers, IT pros, and end users for several releases. Early data suggests that we hit the mark. In addition to describing the improvements we made, we'll address deployment-related questions and provide guidance.

Deploying the .NET Framework to hundreds of millions of machines

Millions of end users rely on .NET Framework apps every day, for entertainment, for social connections, and, of course, to do their work. The apps they use require the presence of the .NET Framework runtime and class libraries. We have improved the .NET Framework 4.5 installation experience for users, so they can install software quickly and easily.

The .NET Framework is also necessary for running ASP.NET websites and Windows Communication Foundation (WCF) services. In most cases, the installation improvements we made for end users also help developers and IT pros who maintain servers.

Over the years, we’ve adopted a broad set of strategies to get the .NET Framework installed on end user machines. As a result, end users can run the apps they want, without needing to understand that they depend on the .NET Framework. This is primarily accomplished by giving developers and enterprise IT pros the tools they need to install the .NET Framework as part of their existing software deployment methods. We also include the .NET Framework with Windows and deliver it through Windows Update, which removes the need to install the .NET Framework as a separate step in many cases.

We think of our relationship with you, as developers and enterprise IT pros, as a partnership for delivering a great experience to our shared customer, the end user. We are all successful when the end user can quickly acquire, install, and start using your app, and can easily install the .NET Framework as part of your app's setup. Through your apps, we have installed the .NET Framework 4 on hundreds of millions of computers, and on well over half of machines running Windows throughout the world. We want to build on that success as you adopt the .NET Framework 4.5 and enjoy the improvements we’ve made available.

Content in this post:

  • Improvements in .NET Framework 4.5 setup
  • How end users get the .NET Framework 4.5
  • Building app setup programs that include the .NET Framework 4.5
  • Treatment of the .NET Framework 4
  • Detecting the .NET Framework

Improvements in .NET Framework 4.5 setup

With the .NET Framework 4.5, we wanted to be ready to reach over a billion end users. To a large degree, we focused on improvements that would benefit end users. Those same improvements will also benefit you, as developers and IT pros, to help you more easily deploy the .NET Framework 4.5 with your apps.

Before we go into the improvements that we made, it is important for you to understand the basic characteristics of the new release. It is best to think of the .NET Framework 4.5 as a service pack of the .NET Framework 4 with new features. As part of its installation, it updates and replaces the .NET Framework 4.

The following sections discuss three major improvements we made:

  • Providing a single offline .NET Framework installer for supported platforms
  • Reducing system restarts
  • Improving installation reliability

The single installer and the improvements to reduce reboots require a small degree of coordination from you. You can think of this coordination as another way in which we are partnering to provide a great experience to end-users.

Single .NET Framework installer

In earlier releases of the .NET Framework, we provided multiple variations of the .NET Framework installer for you to choose from. These variations included client and extended installers, and separate downloads for x86, x64, and IA64 machine architectures.

The biggest motivation for creating these separate installers was file size. We didn’t want to burden apps with functionality that they didn’t need. These decisions were made during a time when many developers distributed their apps on CDs and DVDs. In some cases, they didn’t allow much space for the .NET Framework, so we needed to find ways to fit. However, developers sometimes chose the wrong installer, which left end users with a non-optimal experience.

As part of the .NET Framework 4, we shipped a Client Profile installer that was 41 MB and supported both x86 and x64 platforms. Many of you were enthusiastic about the Client Profile, because it was much smaller than the full .NET Framework 3.5 installer (which was around 250 MB) and supported both x86 and x64 machines. However, it wasn't always obvious when the Client Profile was appropriate to use. In some cases, apps installed the Client Profile, but used third-party controls and libraries that needed the full profile.

Our telemetry shows that a large number of .NET Framework 4 apps need the full profile. We know that thousands of end users see the following dialog box every day, because they're using apps that installed the .NET Framework Client Profile but needed the .NET Framework 4 full profile. While this dialog box helps end users install the .NET Framework version they need, it is a confusing experience for many people.  Instead, we produced a single profile for the .NET Framework 4.5, removing the Client Profile option. At the same time, we were able to keep the full profile installer for the .NET Framework 4.5 under 50MB, similar to the .NET Framework 4.0, but much smaller than earlier versions.

image

Dialog box displayed when an end user is missing the .NET Framework 4 full profile

Another goal was to reduce the number of chip architectures to consider. In the .NET Framework 4, we merged the x86 and x64 downloads but left IA64 as a separate package. In the .NET Framework 4.5, we noticed the low use of IA64, and eliminated IA64 support.

In the .NET Framework 4.5, we've simplified the choice. You select from two installer types, online and offline:

  • Web installer (bootstrapper)
    • Very small (<1MB)
    • Requires an online connection
    • Downloads and installs only the components needed for a given machine (for example, only x86 components on an x86 machine)
    • Installs the appropriate language pack automatically
  • Standalone (offline) installer
    • 50 MB in size
    • Contains files for all platforms .NET Framework 4.5 supports (x86 and x64 machines)
    • Doesn’t install language packs; you must install the appropriate language packs
    • Doesn't require an online connection

Reducing system restarts

Most end-users have probably had the experience of trying to install an app and getting a dialog box indicating that they have to restart their computer. This happens when an installer cannot update files because they are in use by another process. An easy way to make those files available for updating is to restart the machine. However, there are other approaches that provide a better user experience, so we looked at those options.

The .NET Framework 4.5 installation replaces .NET Framework 4 files and requires those files to be available during installation. Therefore, the setup program has the potential to require a restart if .NET Framework 4 apps are running. To mitigate that situation, we built a restart manager that enables end users to automatically close apps that are using the .NET Framework 4. By doing so, end users can prevent reboots of their machines.

In the example below, an end user receives a prompt that Turbo Tax Premier 2011 is using the .NET Framework 4 and has to be closed. The user clicks Yes to proceed with a reboot-free installation experience. Many users will recognize this prompt from other popular apps and platforms.

image

Restart manager prompt

The setup program displays this prompt when end-users install the .NET Framework directly. When the .NET Framework 4.5 is installed as part of an application's setup, it is usually configured to run in silent mode. By default, .NET Framework 4.5 setup does not show the restart manager in silent mode. However, you can provide this experience to your users with a little extra work on your part. We need your help, because our setup program cannot determine the right point in your app's setup to display the prompt.

Initial data for the .NET Framework 4.5 setup shows that the restart manager feature has eliminated over half of possible reboots. That’s a big improvement.

image

Distribution of reboots for interactive installs

The steps to use the restart manager in silent mode are explained in Reducing System Restarts During .NET Framework 4.5 Installations in the MSDN Library. You may also want to watch the Channel 9 video Reducing Reboots During Framework Installation, which explains the work behind this feature.

Improving installation reliability

After earlier releases of the .NET Framework, we saw that a small percentage of end users were experiencing installation failures that were preventing them from running the .NET Framework apps they wanted. In the .NET Framework 4, we made improvements that reduced this percentage of end users.

However, we knew that we needed to do better. A few years ago, we added better telemetry to .NET Framework 4 setup to get more concrete data about installation reliability. We also used developer feedback from Microsoft Connect to broaden and prioritize our work. As a result, we were able to determine the failure conditions accurately and resolve the most prevalent cases. For example, end users used to encounter installation failures due to adding assemblies into the .NET Framework global assembly cache during installation. This category of failure has been completely eliminated from the .NET Framework 4.5 installation experience.

Early telemetry from .NET Framework 4.5 setup suggests we achieved an important jump in reliability. In the .NET Framework 4.5, we were able to cut the observed failure rate by half. We know that the .NET Framework 4.5 will end up being installed on over a billion machines globally, so this improvement is a critical one.

We have data about the reliability of our setup in a number of different environments. For example, we have seen very high success rates when the .NET Framework 4.5 is chained (included) with a custom setup program. In terms of corporate roll-outs, we have heard from Microsoft IT that the .NET Framework roll-out across Microsoft was very successful. Early discussions with large customers suggest very similar results with corporate-wide rollouts. That’s great to hear. We should also note that we rolled out the .NET Framework 4.5 Beta and RC across large subsets of Microsoft (>10,000 installations with each prerelease) as part of ensuring that we were delivering a highly reliable product. We know that we’ve delivered a product with the right reliability characteristics and that you can take a dependency on it with confidence.

How end users get the .NET Framework 4.5

Many end-users will use the .NET Framework 4.5 over the next several years, possibly as part of installing and running your app. To support these users, we have established a broad set of distribution channels.

Supported operating systems

The .NET Framework 4.5 is already built into the following operating systems, so it doesn't require separate installation:

  • Windows 8
  • Windows Server 2012

The .NET Framework 4.5 can also be installed on the following systems, by downloading the redistributable installer (web or offline), which supports both x86-based and x64-based computers:

  • Windows Vista SP2
  • Windows 7 SP1
  • Windows Server 2008 R2 SP1
  • Windows Server 2008 SP2

Distribution channels

The .NET Framework 4.5 can be deployed through the following distribution channels.

For consumer users:

For enterprise users:

In enterprises, users typically get the .NET Framework deployed as a part of a deployment/update channel managed by an administrator. System Center deployments and Windows Server Update Services (WSUS) are commonly used for a variety of software, including the .NET Framework. By using WSUS, administrators can manage the distribution of updates that are released through Windows Update to computers in their network. Detailed instructions on using System Center for .NET Framework deployments are provided in the Deployment guide for Administrators.

Building app setup programs that include the .NET Framework 4.5

After you have built your app, you can create an installer by using Visual Studio 2012. You can also create custom installer packages through open source technologies like Windows Installer XML (WiX). Both options will help you create an installer that includes the .NET Framework 4.5 and delivers a great experience to the end user.

Targeting the .NET Framework 4.5

The deployment guide for developers provides detailed information about how to create setup experiences using these tools. Before you build a setup program, you must verify that your app properly targets the .NET Framework 4.5 by using the Target Framework option in Visual Studio. (See How to: Target a Version of the .NET Framework in the MSDN Library for instructions.)

image

Targeting the .NET Framework 4.5 in Visual Studio 2012

Apps that target the .NET Framework 4 will run on the .NET Framework 4.5, but will not be able to use any of the new APIs that are available in the newer version.

In the following sections, we'll look at three ways to build a setup program that deploys the .NET Framework with your app:

  • ClickOnce (available with Visual Studio)
  • InstallShield (available with Visual Studio)
  • Windows Installer XML (WiX) toolset

Building a setup program using Visual Studio and ClickOnce

You can use Visual Studio 2012 to create a setup program for your app by using ClickOnce. The following screen illustration demonstrates how you select the .NET Framework 4.5 as a prerequisite and create a ClickOnce installer in Visual Studio. For step-by-step directions, see the .NET Framework Deployment Guide for Developers.

image

Selecting the .NET Framework 4.5 as a prerequisite in ClickOnce

The following screen illustration shows the end user experience that a setup program built with ClickOnce provides.

image

ClickOnce setup program installing the .NET Framework 4.5

Building a setup program using Visual Studio and InstallShield

You can also use Visual Studio 2012 to create a setup for your app by using Installshield Limited Edition. The following screen illustration shows how to select the version of the .NET Framework redistributable to be included with your app setup. For step-by-step directions, see the .NET Framework Deployment Guide for Developers.

image37

Selecting the .NET Framework 4.5 as a prerequisite using InstallShield

image

Installshield Setup program installing .NET Framework 4.5

Building a setup program using WiX

You may also use an open source installer tool set such as WiX to build a custom installation package. WiX enables you to create an app setup package that installs both your app and the .NET Framework as a prerequisite.

image

Setting the .NET Framework 4.5 as a prerequisite in a WiX setup project in Visual Studio

The following screen illustration shows the end user experience that a setup program built with WiX provides.

image

WiX setup program installing the .NET Framework 4.5

Treatment of the .NET Framework 4

You may be wondering what happens to an existing .NET Framework 4 installation on an end-user machine when the .NET Framework 4.5 is installed. It is also likely that some of your customers will ask you the same question. At a high-level, and as stated earlier, you should think of the .NET Framework 4.5 as a service pack of the .NET Framework 4 that also includes additional features.

The .NET Framework 4.5 installer updates and replaces the .NET Framework 4 installation. After the .NET Framework 4.5 installation completes, an end user will no longer have the .NET Framework 4 on their machine, but will be able to run apps built with both the .NET Framework 4 and 4.5. In addition, Programs and Features in Control Panel will include an entry for the .NET Framework 4.5 but not for the .NET Framework 4.

We chose to create the .NET Framework 4.5 as in-place update of the .NET Framework 4 to enable end users to:

  • Benefit from fundamental improvements made in the .NET Framework 4.5, such as performance and reliability.
  • Experience better performance for .NET Framework 4 and 4.5 apps, since they need to load only one version of the .NET Framework (version 4.5) into memory.
  • Install only one set of servicing updates from Windows Update instead of two.

If an end user uninstalls the .NET Framework 4.5, they will no longer have either the .NET Framework 4 or 4.5 installed on their computer. As a result, they will not able to run apps built with either the .NET Framework 4 or 4.5. Reinstalling the .NET Framework 4.5 will enable them to run these apps again. Reinstalling the .NET Framework 4 would enable them to run apps built with the .NET Framework 4, but not 4.5.

Choosing an installer and detecting the .NET Framework

Before we review some of the common questions about deployment, I’d like to direct you to the following guidance documents on MSDN that we updated for the .NET Framework 4.5:

Deployment guide for developers

http://msdn.microsoft.com/library/ee942965

Deployment guide for administrators

http://msdn.microsoft.com/library/ee390831

Deploying the .NET Framework and applications

http://msdn.microsoft.com/library/6hbb4k3e

Q: Which .NET Framework 4.5 installer should I select?

A: Choose the right installer to provide the best application installation experience to your customers. The two installers have the following characteristics, which should help you make the right choice.

  • Web installer (bootstrapper)
    • Pro: Very small (<1 MB)
    • Pro: Downloads only the components required by the target platform
    • Pro: Installs the language pack for end-users, per operating system locale
    • Requirement: Internet connection
  • Standalone (offline) installer
    • Pro: Contains files for all.NET Framework platforms, for x86 and x64
    • Pro: Offline-capable, but larger size
    • Requirement: You must install language packs separately

Locations:

Web bootstrapper

http://go.microsoft.com/fwlink/?LinkId=225704

Standalone installer

http://go.microsoft.com/fwlink/?LinkId=225702

Q: How do I detect the .NET Framework 4.5?

A: You can detect the presence of the .NET Framework 4.5 by checking for the new Release registry key, which we added in the .NET Framework 4.5. The new key is of type REG_DWORD, which enables simple numeric evaluation such as greater than or equal to (>=). To determine whether the .NET Framewework 4.5 has already been installed on the end user's computer, your app installer should check for a Release value that is greater than or equal to 378389. Checking just for equality may be insufficient, because we may increase the value of the Release key in a later update.

To check for the presence of the .NET Framework 4.5, use:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full

Release >= 378389

Q: Which .NET Framework version do I check if my app runs on both the .NET Framework 4 and 4.5?

A: You can check for the presence of the .NET Framework 4, and if either the .NET Framework 4 or 4.5 is present, the detection test will return true. To do this, check for the existence of a registry key named Install, as explained in the “Detecting the .NET Framework 4” section of the .NET Framework Deployment Guide for Developers.

To check for the presence of the .NET Framework 4, use:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full

Install

Q: I’m using the Version key to detect the .NET Framework. Should I switch to a different key?

A: The Version key is of type REG_SZ, which represents a string such as 4.0.0.0. Numeric comparisons based on strings are inherently difficult and error-prone. Instead of using the Version key, you should use the Release or Install key, as described above.

Conclusion

In this post, we looked at the improvements we've made to .NET Framework 4.5 setup. We hope that these improvements help you, as app developers and enterprise IT pros, distribute the .NET Framework more easily with your apps, as well as making the installation experience faster and easier for our shared customer, the end-user.

Once again, you may want to watch the Channel 9 video Reducing Reboots During Framework Installation, which explains the work behind one of the new improvements.

We hope that you are as excited about these improvements as we are. Please send us your feedback.

Send reports of compatibility issues to netfx45compat@microsoft.com.

Follow or talk to us on twitter -- http://twitter.com/dotnet.

Leave a Comment
  • Please add 8 and 6 and type the answer here:
  • Post
  • What about deploying .NET 4 app on WinXP environments? If I install and develop an app with Visual Studio 2012 targeting Framework 4 and can let bugs pass without notice because bits in my machine have fixes but in WinXP they stuck in Framework 4 without fixes.

    Any plans to provide only the updates to WinXP and above?

  • Also, I read your prerequisite as saying .NET 4.5 will install in Win7 SP1 but not on Win7, and that it will install on WinVista SP2 but not on WinVista and not on WinVista SP1. have I incorrectly interpreted what you are saying? Because the though of what I just said being true would be amazingly shocking to me, surely it runs on Vista original and beyond, right? I am already amazed that it will not run on Windows XP, but the thought of it requiring latest service packs on the last two operating systems would just be astonishing. You may as well have said this .NET 4.5 was written to be used 10 years from now, when 99% of Windows computers will be able to run it. This is a joke, right?

  • Brandon you are right in your first line:

    The only experience most Microsoft customers have with the .NET Framework is the deployment and installation experience, which is why we spend so much time analyzing opportunities to improve it.

    And in my opinion it's a relatively bad 'experience'. 9 of 10 times a .NET update comes along via WSUS it's a pain in the ass.

    The latest update for .NET 4.5.1 caused several applications to be restarted by RestartManager ending up with an 10010 event in the log and unusable state. While we still reboot the servers after all updates are done, one application had a config corruption due to this RestartManager 'feature'. We had to restore the config in our production environment. Applications that were affected by 10010 error also included system center products like sccm, scom and orchestrator.

    In case anyone starts wondering: we test all updates before production, but this particular error (causing the config to become corrupt) did not occur there.

Page 1 of 1 (3 items)