In the early days of personal computing, constructing an application that could be installed successfully on another computer was often as simple as compiling an .exe file and copying it to a floppy disk. As applications have become increasingly complex and sophisticated, the number of files needed for a typical installation has grown from a handful of files to several hundreds.
This is especially true with Windows applications, which have historically required sophisticated setup programs to copy the correct dynamic link libraries (DLLs) and support files to the end user's computer and to register the applications appropriately with the operating system. This first of a two-article series discusses the features provided by the .NET Framework for deploying Windows applications onto the end user's machine. To this end, it discusses the different types of deployment options the .NET Framework provides. It also takes a look at the architecture of the Windows Installer and then goes on to discuss the differences between XCOPY and Windows Installer. Along the way, it demonstrates the process of packaging up Windows forms applications using the setup and deployment project types supported by Visual Studio.NET.
Setup Versus Deployment
Before you can understand the processes involved in setting up and deploying applications, you need to understand the difference between setup and deployment. A setup is an application or process that allows you to package up your application into an easy-to-deploy format, which then can be used to install the application on another machine. Deployment is the process of taking the application and installing it in on another machine, usually by using a setup application.
Planning for Deployment
At one time or another, most computer users have experienced the dark side of installing Windows programs. For example, in the pre-.NET era, when you installed a new version of your Windows application, the installation program copied the new version of your DLLs into the system directory and made all the necessary Registry changes. This installation could impact other applications running on the machine, especially if an existing application was using the shared version of the installed component. If the installed component was backward compatible with the previous versions, then it was fine. In many cases, however, backward compatibility may be impossible to maintain. If you cannot maintain backward compatibility, you often end up breaking the existing applications as a result of new installations.
One of the areas Visual Studio .NET was designed to address was the installation shortcomings of Windows applications that relied heavily on COM components. Visual Studio .NET can simplify the installation process because Visual Studio .NET applications rely on .NET assemblies (which are built on a completely different programming model) for much of their functionality. In addition, Visual Studio .NET applications compile as assemblies, a deployment unit consisting of one or more files.
To fully understand how Visual Studio .NET simplifies the deployment process, take a brief look at the structure of the assembly that provides for this simplification. Assemblies contain four elements:
- MSIL (Microsoft Intermediate Language) code—Language code (C#, VB.NET, and others) is compiled into this intermediate common language that can be understand by the common language runtime (CLR).
- Metadata—Contains information about the types, methods, and other elements defined in the code
- Manifest—Contains name and version information, a list of included files in the assembly, security information, and so on
- Non-executable content, such as supporting files and resources
As you can see, assemblies are so comprehensive and self-describing that Visual Studio .NET applications don't need to be registered with the Registry. This means that Visual Studio .NET applications can be installed by simply copying the required files to the target machine that has the .NET Framework installed. This is called XCOPY installation. However, it is also possible to automate the setup process by making use of the deployment projects that Visual Studio .NET provides. The next section examines Visual Studio .NET's various deployment options.
.NET Deployment Options
You can deploy Windows forms applications using any one of the following two deployment options:
- XCOPY deployment
- Deployment using Visual Studio .NET Installer
The following sections discuss both these deployment options and explains when to use each.
Using XCOPY for Deploying Applications
The .NET framework simplifies deployment by enabling XCOPY deployment. Prior to .NET, installing a component required copying the component to the appropriate directories and making the appropriate Registry entries. But with XCOPY deployment, all you have to do to install the component is copy the assembly into the bin directory of the client application. The application will be able to start using it right away because of the self-describing nature of the assembly. This is possible because compilers in the .NET framework embed identifiers or metadata into compiled modules, and the CLR uses this information to load the appropriate version of the assemblies. The identifiers contain all the information required to load and run modules and to locate all the other modules referenced by the assembly.
An XCOPY deployment is also called a zero-impact install because the way you configure the Registry entries and the component does not impact the machine. This zero-impact installation also makes it possible to uninstall a component without affecting the system in any manner. All you need to do is remove the specific files from the specific directory.
Silverlight 2 SDK for Visual Studio 2008
Article: What Does it Take to Build the Best RIA? 
Expression Blend 2.5 Preview
The Hottest Mobile Platform Meets the Hottest RIA Platform 
Article: Leveraging Your Flash Development with Silverlight 
IE 7
Firefox 2.0
