Several folks have installed the final release of the .NET Framework 2.0 and then contacted me asking about a set of files that gets installed to the folder %windir%\Microsoft.NET\Framework\v2.0.50727\Microsoft .NET Framework 2.0 that they did not see installed with the .NET Framework 1.0 or 1.1. I wanted to take this chance to explain some of the history that led to this behavior in .NET Framework 2.0 setup.
The short explanation
The files in this folder are a copy of the original setup files that are being stored by the .NET Framework 2.0 setup to allow you to repair the product later on without requiring you to re-download the original source setup package (dotnetfx.exe).
The long explanation
The .NET Framework is packaged as a self-extracting executable. That means that when you run setup by double-clicking dotnetfx.exe or by installing some other application that runs dotnetfx.exe behind the scenes, setup extracts itself to a folder created on the fly in the %temp% directory, installs from there and then deletes the folder in %temp% that it just installed from.
By default, Windows Installer will store the source location that a package is installed from in the registry and then use that if it detects that any of the components are broken and needs to repair. In the .NET Framework 1.0 and 1.1, after installation completed, the source location registered by Windows Installer was deleted and any future repair request would prompt the user to browse for the file netfx.msi and list the default path as %temp%\IXP000.tmp (the temporary folder that is deleted at the end of setup).
This means that all resiliency repairs in .NET 1.0 and 1.1 will prompt for a path if they are invoked in UI mode, and they will fail silently if they are invoked in silent mode. This also means that there is not a repair option if you look at the Add/Remove Programs entry for .NET 1.0 and 1.1 because there is not a guarantee that source files would be available to use to perform the repair. To compensate for this limitation, we shipped a file named %windir%\Microsoft.NET\Framework\v1.0.3705\repair.htm and %windir%\Microsoft.NET\Framework\v1.1.4322\1033\repairRedist.htm to describe how to perform a manual repair of the .NET Framework if needed.
After .NET 1.0 and 1.1 shipped and we started releasing hotfixes and service packs, this repair scenario became very bad. When trying to install a patch, Windows Installer performs a component health check, and if anything is detected as broken, it will trigger a resiliency repair. Because of the source files being deleted during installation as described above, the resiliency repair will fail or prompt for a path. In most cases, .NET Framework hotfixes are installed silently via Windows Update. Since setup is run in silent mode, any resiliency repairs will fail with no indication about why, and then the only message seen on Windows Update is a generic message that the .NET Framework hotfix failed to install.
How source caching works in .NET Framework 2.0
In the .NET Framework 2.0, we designed a feature to allow setup to store copies of the original installation files on the hard drive so that resiliency repairs could happen automatically and to allow the user to initiate a repair from Add/Remove Programs. This strategy was inspired by the Office setup team’s local cache feature. The files that are used during the original setup are authored into the MSI and installed to %windir%\Microsoft.NET\Framework\v2.0.50727\Microsoft .NET Framework 2.0 during the initial setup. In addition, the Add/Remove Programs entry is authored to point to the copy of install.exe in this folder instead of to the default msiexec /x command. Finally, a Windows Installer API available starting in Windows Installer 3.0 (MsiSourceListSetInfo) is called to register the source path for the installation to be this folder instead of the default location (which in this case is the path that setup is originally run from that gets deleted automatically at the end of installation). Calling this API allows resiliency repairs to occur without any user intervention.
When we start releasing hotfixes for the .NET Framework 2.0, we expect to see a significantly lower failure rate, especially for hotfixes installed via Windows Update. This lower failure rate will be partly due to the work done to store the source files for the .NET Framework 2.0 because it will make it much more likely that the .NET Framework will not fail the initial health check during hotfix installation, and even if it does, the resiliency repair will be able to silently succeed and allow hotfix setup to proceed in cases where it would have otherwise failed in .NET 1.0 and 1.1.