Deploying the .NET Framework and Applications
This article helps you get started deploying the .NET Framework with your application. Most of the information is intended for developers, OEMs, and enterprise administrators. Users who want to install the .NET Framework on their computers should read Installing the .NET Framework.
Key Deployment Resources
Use the following links to other MSDN topics for specific information about deploying and servicing the .NET Framework.
Setup and deployment
General installer and deployment information:
Deploying the .NET Framework with a client application (for developers):
Deploying the .NET Framework (for OEMs and administrators):
For general information, see the .NET Framework blog
Features That Simplify Deployment
The .NET Framework provides a number of basic features that make it easier to deploy your 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.
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.
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.
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.
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.
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.
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.
|How the Runtime Locates Assemblies||Describes how the common language runtime determines which assembly to use to fulfill a binding request.|
|Best Practices for Assembly Loading||Discusses ways to avoid problems of type identity that can lead to InvalidCastException, MissingMethodException, and other errors.|
|Reducing System Restarts During .NET Framework 4.5 Installations||Describes the Restart Manager, which prevents reboots whenever possible, and explains how applications that install the .NET Framework can take advantage of it.|
|Deployment Guide for Administrators||Explains how a system administrator can deploy the .NET Framework and its system dependencies across a network by using System Center Configuration Manager (SCCM).|
|Deployment Guide for Developers||Explains how developers can install .NET Framework on their users' computers with their applications.|
|Deploying Applications, Services, and Components||Discusses deployment options in Visual Studio, including instructions for publishing an application using the ClickOnce and Windows Installer technologies.|
|Publishing ClickOnce Applications||Describes how to package a Windows Forms application and deploy it with ClickOnce to client computers on a network.|
|Packaging and Deploying Resources||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.|
|Deploying an Interop Application||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.|
|How to: Get Progress from the .NET Framework 4.5 Installer||Describes how to silently launch and track the .NET Framework setup process while showing your own view of the setup progress.|
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.