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
Title |
Description |
|---|---|
Describes how to configure and deploy client applications that target the .NET Framework Client Profile. |
|
Describes how to build and deploy a class library that runs on a variety of .NET Framework platforms without recompilation. |
|
Describes how the common language runtime determines which assembly to use to fulfill a binding request. |
|
Discusses ways to avoid problems of type identity that can lead to InvalidCastException, MissingMethodException, and other errors. |
|
Explains how a system administrator can deploy the .NET Framework and its system dependencies across a network by using System Center Configuration Manager (SCCM). |
|
Explains how developers can install .NET Framework on their users' computers with their applications. |
|
Discusses deployment options in Visual Studio, including instructions for publishing an application using the ClickOnce and Windows Installer technologies. |
|
Describes how to package a Windows Forms application and deploy it with ClickOnce to client computers on a network. |
|
Describes the hub and spoke model that the .NET Framework uses to package and deploy resources; covers resource naming conventions, fallback process, and packaging alternatives. |
|
Explains how to ship and install interop applications, which typically include a .NET Framework client assembly, one or more interop assemblies representing distinct COM type libraries, and one or more registered COM components. |
|
Provides requirements and instructions for installing applications for use by COM clients. |
|
Describes how to silently launch and track the .NET Framework 4 setup process while showing your own view of the setup progress. |