Deploying the .NET Framework


After determining which computers participate in your distributed .NET-based application require the .NET Framework, you need to ensure that the Framework is installed correctly on the appropriate computers in your production environment.

Requirements for Deploying the .NET Framework

There are certain minimum requirements that need to be met so that you can deploy the .NET Framework within your organization. The following table lists the minimum requirements

Table 1.1: Minimum Requirements for deploying the .NET Framework

Client

Server

Pentium 90 MHz

Pentium 133MHz

32 MB RAM (96 MB recommended)

128 MB RAM (256 MB recommended)

Windows 98 or above

NT 4.0 or above (Windows 2000 or above for ASP.NET applications [see Note])

Windows Installer 2.0

Windows Installer 2.0

Note

ASP.NET applications require Windows 2000 as a minimum because they require IIS v5.0, which cannot run on the Microsoft Windows NT 4.0 operating system.

Further Requirements for .NET-based Applications

In addition to the Framework itself, some applications will have other requirements as shown in the following table.

Table 1.2: Requirements for some .NET-based Applications

Client

Server

Internet Explorer 5.01

IIS 5.0 (for ASP.NET applications)

MDAC 2.6

ASP.NET

WMI

MDAC 2.6

WMI

Note

The table lists minimum requirements. Wherever possible you should use the latest version of each to minimize security risks to your environment.

Rather than manually ensuring dependencies such as MDAC and WMI are correctly installed before you roll out your solution to the production environment, you might want to build checks into your setup routines to detect whether these dependencies are present. If they are not installed, you can then automatically install them along with your application.

We will discuss each dependency in more detail:

Internet Explorer 5.01

It is possible to run some .NET-based applications using versions of Internet Explorer 5.01. However this version is quoted as a minimum requirement as it is the first to support all of the added functionality required by .NET-based applications, including code download, cryptography APIs, intranet / Internet zone detection within the CLR and multilanguage support for international encodings.

Microsoft Data Access Components (MDAC)

Microsoft Data Access Components (MDAC)are a collection of core files provided to help applications by providing a means of accessing data. MDAC includes core files for Open Database Connectivity (ODBC), ActiveX Data Objects (ADO), OLEDB, Network libraries, and client configuration tool for SQL Server.

Depending on your data access strategy, you may need to ensure that MDAC is installed on the client computers, the business servers, the Web servers, or the database servers. MDAC 2.6 or later is required by the .NET Framework, and at least MDAC 2.7 SP1 is recommended.

You should ensure that you use the same version of MDAC in the development environment that exists in your production environment. This will help to minimize any problems with transferring the application from the development environment to the production environment.

The latest version of MDAC is available for download at Microsoft's Universal Data Access Web Site.

Microsoft Internet Information Services (IIS)

If your solution includes ASP.NET applications or Web services, you need to ensure that IIS and the latest security patches are installed on your Web server(s). IIS is not installed with the Microsoft Windows Server 2003 operating system by default as it is not always required. It can be installed from the operating system installation CD or DVD. The latest security patches can be downloaded and installed from the Windows Update site.

Microsoft Windows Management Instrumentation (WMI)

WMI defines a nonproprietary set of environment-independent specifications that allow management information to be shared between management applications running in both similar and dissimilar operating system environments. WMI provides enterprise management standards and related technologies that work with existing management standards, such as Desktop Management Interface (DMI) and Simple Network Management Protocol (SNMP). WMI complements these other standards by providing a uniform model. This model represents the managed environment through which management data from any source can be accessed in a common way.

If your solution uses WMI features, you need to ensure that the core WMI is installed on your target computers. WMI is included as a standard feature in Windows Server 2003, Windows XP, Windows 2000, and Windows Me. Additionally, it is automatically installed by Visual Studio .NET on Windows 95, Windows 98, and Windows NT 4.0. However, if your target computers do not have the core WMI installed, a setup package can be downloaded and installed from MSDN Code Center .

For more information on WMI see "Microsoft Windows Management Instrumentation: Background and Overview" on MSDN.

The Framework is deployed using the.NET Framework redistributable package, which can be obtained from MSDN or the Windows Update Web site . Alternately, you can also obtain the redistributable package on a product CD or DVD. Dotnetfx.exe is available on the .NET Framework SDK, and on the Microsoft Visual Studio .NET 2003 DVD.

The .NET Framework redistributable package is actually a Windows Installer package that is wrapped into a single, self-extracting executable file called Dotnetfx.exe. The Dotnetfx.exe executable file launches Install.exe, which performs platform checks, installs Windows Installer 2.0 if necessary, and then launches the Windows Installer package (.msi file).

The following table describes the command line options you can specify when installing Dotnetfx.exe. To specify options when installing Dotnetfx.exe, you must pass the options to the Install.exe wrapper using the /c: option.

Syntax

dotnetfx [/q:a] [/c:"Install [/l][/q]"]

Table 1.3: Command line options for installing Dotnetfx.exe

Option

Description

/l

Creates the setup log, netfx.log, in the %temp% directory. Error codes returned from Dotnetfx.exe are written to this log.

/q

Specifies quiet install mode. Suppresses the display of the setup user interface. For a quiet install, you must also specify the Dotnetfx.exe /q:a option to suppress the extraction user interface.

You should use the Windows Add/Remove Programs option to uninstall a .NET Framework-based application that hosts Dotnetfx.exe. This ensures that Dotnetfx.exe will not be uninstalled independently of an application that is dependent on it in order to run.

Note

For more information on using Dotnetfx.exe see the document the .NET Framework Redistributable Package 1.1 Technical Reference. For further details see "More Information" at the end of this chapter.

Note

If you choose to use Dotnetfx.exe for distributing your application, you must have a valid, licensed copy of the Microsoft .NET Framework SDK and agree to abide by the terms of the Microsoft .NET Framework SDK end user license agreement (EULA).

The Framework will generally be deployed in one of two ways:

  • Preinstalling to any computers that will require it.

  • Installing alongside .NET-based Applications.

We will look at each of these in more detail:

Preinstalling the .NET Framework

If you plan on using the Framework widely throughout your organization it often makes sense to deploy it before you deploy your .NET-based applications. There are a number of methods you can use to ensure that the Framework is distributed to those computers that require it. These include:

  • Microsoft Systems Management Server (SMS)

  • Group Policy

  • Network Share

  • E-mail

  • Internal Web site

  • Microsoft Web site

The .NET Framework Redistributable Package installs significant run-time components onto a target computer. This means that the user initializing the .NET Frame-work setup must have administrator privileges for that computer (or be able to perform the installation with elevated privileges). This requirement has implications for how you choose to deploy the .NET Framework. For example, using Group Policy software deployment to install the package over the network allows you to ensure that the package installs with elevated privileges. Similarly, using SMS allows you to install the Framework with the required permissions. However, if you expect your users to initialize the setup of the .NET Framework, either locally or over the network, then you (or your systems administrator) must ensure that the user has administrator privileges on his or her local computer or can run the installation with elevated privileges.

Note

To install the Framework using Group Policy or SMS, you first need to extract the Windows Installer file from dotnetfx.exe. For more details on how to do this, see: "Redistributing the .NET Framework" on MSDN

Installing Alongside Framework Applications

In some cases, where you cannot pre-determine which computers will require the .NET Framework in advance, you may choose to install the Framework only when it is required, in other words when a .NET-based application is installed. This approach is particularly useful when you are developing and packaging your Framework application for general sale, or perhaps for installation onto a number of different customer networks, and you do not have any knowledge of the infrastructure where your application is to be deployed. You can do this by using the setup.exe Bootstrapper sample. This sample checks to see if the Framework has already been installed, and if it hasn't, it will then install the Framework prior to installing the application.

Note

For more information on using the setup.exe Bootstrapper sample, see Chapter 3, "Implementing the Deployment of .NET-Framework based Applications."




Deploying. NET Applications Lifecycle Guide
Deploying .NET Applications: A Lifecycle Guide: A Lifecycle Guide (Patterns & Practices)
ISBN: B004V9MSJW
EAN: N/A
Year: 2003
Pages: 53

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net