This article is specific to .NET Framework. It doesn't apply to newer implementations of .NET, including .NET 6 and later versions.
This article helps you get started deploying .NET Framework with your application. Most of the information is intended for developers, OEMs, and enterprise administrators. Users who want to install .NET Framework on their computers should read Install .NET Framework.
Key Deployment Resources
Use the following links to other MSDN topics for specific information about deploying and servicing the .NET Framework.
The .NET Framework provides a number of basic features that make it easier to deploy your applications:
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 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 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.
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.
Describes the Restart Manager, which prevents reboots whenever possible, and explains how applications that install the .NET Framework can take advantage of it.
Explains how a system administrator can deploy the .NET Framework and its system dependencies across a network by using Microsoft Endpoint Configuration Manager.
Discusses deployment options in Visual Studio, including instructions for publishing an application using the ClickOnce and Windows Installer technologies.
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.
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
.NET feedback
.NET is an open source project. Select a link to provide feedback: