Deploying the .NET Framework and Applications

The .NET Framework provides a number of basic features that make it easier to deploy your applications. These features include the following:

• No-impact applications.

  This feature provides application isolation and eliminates DLL conflicts. By default, components do not affect other applications.

• Private components by default.

  By default, components are deployed to the application directory and are visible only to the containing application.

• Controlled code sharing.

  Code sharing requires you to explicitly make code available for sharing instead of being the default behavior.

• Side-by-side versioning.

  Multiple versions of a component or application can coexist, you can choose which versions to use, and the common language runtime enforces versioning policy.

• XCOPY deployment and replication.

  Self-described and self-contained components and applications can be deployed without registry entries or dependencies.

• On-the-fly updates.

  Administrators can use hosts, such as ASP.NET, to update program DLLs, even on remote computers.

• Integration with the Microsoft Windows Installer.

  Advertisement, publishing, repair, and install-on-demand are all available when deploying your application.

• Enterprise deployment.

  This feature provides easy software distribution, including using Active Directory.

• Downloading and caching.

  Incremental downloads keep downloads smaller, and components can be isolated for use only by the application for low-impact deployment.

• Partially trusted code.

  Identity is based on the code instead of the user, and no certificate dialog boxes appear.

Packaging and Distributing .NET Framework Applications

Some of the packaging and deployment information for the .NET Framework is described in other sections of the documentation. Those sections provide information about the self-describing units called assemblies, which require no registry entries, strong-named assemblies, which ensure name uniqueness and prevent name spoofing, and assembly versioning, which addresses many of the problems associated with DLL conflicts. The following sections provide information about packaging and distributing .NET Framework applications.

Packaging

The .NET Framework provides the following options for packaging applications:

• As a single assembly or as a collection of assemblies.

  With this option, you simply use the .dll or .exe files as they were built.

• As cabinet (CAB) files.

  With this option, you compress files into .cab files to make distribution or download less time consuming.

• As a Windows Installer 2.0 package or in other installer formats.

  With this option, you create .msi files for use with the Windows Installer, or you package your application for use with some other installer.

Distribution

The .NET Framework provides the following options for distributing applications:

• Use XCOPY or FTP.

  Because common language runtime applications are self-describing and require no registry entries, you can use XCOPY or FTP to simply copy the application to an appropriate directory. The application can then be run from that directory.

• Use code download.

  If you are distributing your application over the Internet or through a corporate intranet, you can simply download the code to a computer and run the application there.

• Use an installer program such as Windows Installer 2.0.

  Windows Installer 2.0 can install, repair, or remove .NET Framework assemblies in the global assembly cache and in private directories.

Installation Location

To determine where to deploy your application's assemblies so they can be found by the runtime, see How the Runtime Locates Assemblies.

Security considerations can also affect how you deploy your application. Security permissions are granted to managed code according to where the code is located. Deploying an application or component to a location where it receives little trust, such as the Internet, limits what the application or component can do. For more information about deployment and security considerations, see Code Access Security Basics.

Related Topics