.NET Framework 1.1 deployment guide

  • Article

There is a pretty good document published on MSDN that provides a technical overview of various topics related to deploying the .NET Framework 1.1. It provides information related to mass-deployment to a network of computers, and also information related to redistributing the .NET Framework 1.1 as part of another setup package (for managed applications that want to bootstrap the .NET Framework if it is not installed instead of blocking and forcing the user to install it themselves).

You can find this article at this location. Here are a few of the important topics covered in this article:

  1. How to deploye the .NET Framework 1.1 via SMS (listed in the section named "Deploying the .NET Framework using Systems Management Server")
  2. How to deploye the .NET Framework 1.1 via Active Directory (listed in the section named "Deploying the .NET Framework using Active Directory")
  3. Detecting whether or not the .NET Framework 1.1 is installed (listed in the section named "Detecting that the .NET Framework 1.1 is installed")
  4. Detecting whether or not .NET Framework 1.1 language packs are installed (listed in "Table 2. .NET Framework Registry Locations")
  5. How to determine whether or not installing the .NET Framework 1.1 succeeded when it is chained as part of another product's setup package (there is a list of options in the section named "How to Determine If the .NET Framework, J# Redistributable Package, or Language Pack Installed Successfully From a Setup Package That Installs It As a Prerequisite")

Now if I can only get all of the setup developers inside of Microsoft who redistribute the .NET Framework to follow these guidelines, I'll be making some progress. I see way too many cases where setup developers choose random registry values or files and start using them to detect the presence or absence of the .NET Framework. Invariably, if someone follows undocumented strategies and relies on behaviors that are observed but not officially supported, it can lead to compatibility issues when later versions of the .NET Framework are released if the behaviors are changed. Microsoft product teams will not scrutinize or question behavior changes as much if they are not publicly documented because they tend to assume that others (inside and outside of Microsoft) will rely on officially documented behaviors when designing their own solutions.

<update date="1/14/2009"> Fixed broken link to the .NET Framework 1.1 deployment guide on MSDN. </update>