- What is going up on WU and WSUS?
- What is the error rate and has .NET team done anything to minimize failures?
- Will this impact older .NET application?
- Why should I install .NET 4?
What is on WU?
Three things were released on WU (6/22/2010).
The first item is .NET Framework 4 Client Profile. On Vista and Windows 7 computers it is a recommended update that can be automatically installed. If the OS is setup to install recommended updates the user does not need to do anything. WU Client will install .NET 4 Client the next time it checks for an update. If the computer only takes critical updates or runs XP then the user will need to manually run WU and select the .NET Framework 4 Client Profile.
Server OSs (Windows 2003, Windows 2008 and Windows 2008 R2) will see .NET Framework 4 as an optional update. The Client Profile is not offered on server machines. The .NET team has adopted a philosophy of let IT folks manage their servers by giving them options and control.
Finally, an update to .NET 3.5 SP1 is going out. This affects .NET 4 due to the fact that in updating .NET 3.5 SP1 an intentional side effect is to make .NET 3.5 SP1, .NET 4 aware. This means that if you try to run a .NET 4 application that has this update but does not have .NET 4 installed, an appropriate error message is displayed including redirecting the user to install .NET 4. In most cases installing .NET 4 on top of this update will probably not require a reboot, although it still requires elevated privileges.
What is on WSUS?
Administrators using WSUS will see a slightly different story. .NET Framework 4 will be optional on all the above OSs, while .NET Framework 4 Client Profile will be optional on XP and recommended on Vista and Windows 7.
What is the error rate?
What is really being asked is, "How much will .NET on WU/WSUS consume?" Let me backup and talk about goals in building .NET 4. The .NET team made non-impactful installation a key goal. Or put another way. Users should have a better installation success rate. In addition, older .NET applications should continue to function and behave as if you had not installed .NET 4. The end result of the efforts is an installation package that has a higher success rate and only one known issues with .NET 4 running side by side with older versions.
The one know issue is actually not a bug in .NET but .NET 4 exposing a bug in how certain native products calling into manage code failed to request a specific version of the CLR. The manage code then fails because it does not work on .NET 4. The affected Microsoft products (BizTalk and Host Integration Services) have issued a patch. For more details and a fix see KB2252691 FIX: 0x80131700 error code when starting or configuring the Enterprise Single Sign-On Service.
The average installation success rate depends on the environment. The average the success rate in unmanaged environments is around 97+%. In managed environments, the success rate can be 99+%. Microsoft IT as part of our testing rolled out .NET 4 to over 40k computers within Microsoft with a 99.5+% installation success rate.
How did the .NET team accomplish high deployment rates and ensuring that installing .NET 4 did not break older applications? It goes back to the key goal, non-impactful installation. This goal of .NET 4 meant that installing .NET 4 must not affect .NET programs written for older versions. In order to fulfill this principal, the .NET team did several things including
- Made .NET 4 a side by side installation.
- Teams contributing to .NET 4 did extensive testing regarding interactions between Frameworks.
- Product engineering partnered with both internal and external teams to test specifically for non-impactful install.
- Add feature to installation called "Find It Fix It"
.NET 4 is a side by side release. This means that .NET 4 installs in a separate directory from other versions of the Framework. There are only a handful of binaries that are shared between all versions of the Framework. These binaries act as shims to direct the calling process to the right version of the binary to use. In addition, .NET 4 does not force .NET programs to use .NET 4. Unless the program is explicitly told to run on .NET 4, it will continue to require and run on the older version. If a program requires .NET 3.5 SP1 it must be installed. If it is not installed, the .NET Framework will ask the user to install the missing version. This is a change from our old story of just install the latest version and everything will work. However, with the old story at times application compatibility was broken. The new strategy of preserving application compatibility trumped the old strategy and now requires .NET 3.5 SP1 and .NET 4 to both be installed in order to run .NET 3.5 SP1 and .NET 4 applications.
Product groups involved in building .NET 4 did extensive side by side testing by their quality assurance teams. This involved installing and uninstalling various .NET versions in a variety of ways. For example installing .NET 2.0, installing .NET 4 and testing that .NET 2.0 still functions the same as if .NET 4 was not installed. Or installing .NET 4, .NET 3.5 SP1 and then removing .NET 4. Did teams test all combinations? No, since the combinations are infinite (e.g. install .NET 4, install 2.0, uninstall 4, uninstall 2.0, reinstall .NET 3.5 SP1, etc.) however teams did extensive testing on a reasonable set of combinations.
In building.NET, several customer programs were created. One of those programs was the application compatibility program. This program was charted as part of ensure the goal of non-impactful installation. A team then worked with both internal product groups, internal Microsoft IT, and external groups to do compatibility testing. The primary goal was to ensure that installing .NET 4 did not impact programs written in older versions of .NET. The team published a walkthrough and setup a forum for anyone to use and communicate problems. The team did compatibility workshops with companies. Via these mechanisms over 450 applications were tested. This does not count external customers private testing using the compatibility walkthrough.
"Find It. Fix It." is a feature that adds self-healing into the .NET installation. If the install fails rather than failing, the installer tries to fix the issue and retry the installation. From the user perspective the installation might take longer but in a lot of cases the installation completes and leaves the computer in some cases leaves the computer in a better state than before the installation of .NET 4.
Why should I install .NET 4?
Why not? With non-impactful install you really have little reason. For developers in particular there are a lot of new features. You might say well I am not a developer. You still should install .NET 4 or at least the update in order to be ready to install .NET 4 when your favorite application updates.
Comments