.NET Framework Deployment Basics
Some of the packaging and deployment information for the .NET Framework is described in other sections of the documentation. These 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. This section provides 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 Microsoft 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 Microsoft .NET Framework assemblies in the global assembly cache and in private directories.
To determine how you should package and deploy your particular application, review the scenarios discussed in the Deployment Scenarios section. If you are unfamiliar with the rules for locating 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 policy gives permissions to managed code according to how the code is signed and where it is located. Deploying an application or component to a location where it receives little trust limits what the application or component can do. For more information about deployment and security considerations, see Code Access Security Basics.
See Also
Tasks
How to: Develop a Simple Windows Forms Control
Concepts
Deploying an Application for COM Access
.NET Framework Deployment Features