| Introduction In part one of this article, we saw how to deploy an ASP.NET Web application using different deployment mechanisms such as XCOPY, Copy Project option in Visual Studio .NET, and Visual Studio .NET Web Setup project. In this installment, we will see how to create sophisticated Windows installers by leveraging the features provided by the Visual Studio .NET Web Setup project. We will also see how to take advantage of the different setup editors that are part of the Visual Studio .NET Web Setup Project template. Different Types of Setup Editors When you deploy an application, you may also want to perform operations such as controlling the directory structure of the installed application on the end user's computer, adding registry settings, set ting special conditions, and tweaking user interface displayed during the installation as part of the installation. Because of the flexibility offered by deployment projects in Visual Studio .NET, you can accomplish this very easily. Visual Studio .NET provides the following editors. - File System Editor: This editor is used to add files to the installation package on the target computer
- Registry Editor: Using this editor, you can specify the registry entries that need to be created on the target computer
- File Types Editor: This editor allows you to associate file extensions with applications so that they can be automatically launched when the user tries to open files with those extensions
- User Interface Editor: This editor allows you to configure the user interface dialogs that are shown during the installation
- Custom Actions Editor: Using this editor, you can specify the custom programs that you want the installer to invoke during installs and uninstalls
- Launch Conditions Editor: This editor allows you to specify the minimum requirements for your application to be installed on the target computer
In the next section, you will receive an in-depth look at all of the above editors (with examples on how to make use of them). File System Editor As the name suggests, this editor allows you to add project output files, assemblies, and other files to a specific folder in the deployment project. Using this editor, you can also specify the directory location where these files will be installed on the end user's computer. The File System Editor can be opened by selecting View -> Editor -> File System from the menu. The File System Editor provides a number of pre-defined folders that you can choose to install your application. By using any of the pre-defined folders available in the File System Editor, you can choose a destination folder on a target computer without even having to know the actual path to that folder. Some of the important folders available in File System Editor are: - Application Folder: Application Folder is normally represented by the path [ProgramFilesFolder][Manufacturer][ProductName]. The values for Manufacturer and ProductName directories will be taken from the settings that were specified while setting the project properties.
- Global Assembly Cache Folder: This option allows you to specify the assemblies that will be installed as shared assemblies on the target computer
- User's Desktop: This folder acts as a placeholder for files and folders that should appear on the desktop of the user. The default location of this folder is [DriveName]\Documents and Settings\[UserName]\Desktop, with the UserName representing the name of the user who actually performs the installation.
- User's Program Menu: This folder acts as a placeholder for entries that should appear on the programs group of the user. The default location of this folder is [DriveName]\Documents and Settings\[UserName]\Start Menu\Programs, with the UserName representing the name of the user who actually performs the installation.
For the purposes of this article, let us say that we want to add one of the dependent assemblies used by our application to the Global Assembly Cache Folder. To do this, open up the File System editor by selecting View ->Editor ->File System Editor from the menu. After that, right click on the folder File System on Target Machine and select Add Special Folder -> Global Assembly Cache Folder from within the file system editor. Once you add the folder, it will appear as a child node under the File System on Target Machine node. Now you need to add the required assembly to the Global Assembly Cache folder. You can do this by right clicking on the Global Assembly Cache folder and selecting Add -> Assembly from the context menu. From the Component Selector dialog box, select the assembly that you want to add. Once you add the assembly to this folder, it will be automatically added to the Global Assembly Cache folder on the target machine during installation. Registry Editor As the name suggests, this editor allows you to manage the registry settings in the target computer where the application is installed. By default, the registry editor displays the standard Windows registry keys such as HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and HKEY_USERS. Using the registry editor, you can add custom registry keys under any of the above keys. Selecting View -> Editor -> Registry from the menu brings up the registry editor as shown in the following figure. 
Since the registry editor represents the structure of the registry editor in the target machine, you can use this editor to visually add desired settings and create them in the target machine during installation. Let us say, for example, we want to add application-specific settings under the hive named HKEY_LOCAL_MACHINE. To do this, right click on the HKEY_LOCAL_MACHINE hive, select New Key from the context menu, and add a child node called Software. Now select the Software node and add a child node called 15Seconds. Similarly add another node called ConfigurationSettings under the 15Seconds node. Now right click on the ConfigurationSettings node and select New->String Value. Modify this node and ensure that you add proper values to name and value. After adding the name and value pair, the registry editor should look like the following. 
Now that you have configured the registry editor properly, installing the application on the target machine will result in the registry entry DBConnectionString being added to the registry on the target machine. File Types Editor Using File Types editor, you can set up file associations on the target computer. This is accomplished by linking up the file extension with the application that needs to be launched, when any of the actions specified for the file type are performed. After the initial association is done, the extension and the file type description will appear in the file types list in Windows explorer. This is very useful, if your application uses custom file types that require a separate external application to be launched, when any of the actions specified for the file type is performed. Selecting View -> Editor -> File Types Editor from the menu displays the file types editor. The following table displays the important properties that you need to set in the file types editor while associating a file type with a specific application. Properties associated with the File Types Editor | Property | Purpose | | Name | Determines the name used in the file types editor to identify a particular file type | | Command | Used to set the executable file that should be launched when the user opens a file | | Extensions | Specifies the file extension with which the executable should be registered | | Icon | Specifies an icon to be displayed for the file type | | Description | Provides a brief description for the file type |
Custom Actions Editor This editor allows you to link your installation to another program, which can be launched at the end of the installation. To create a custom action, create a .dll or .exe that performs the custom action and then add it to the deployment project. Remember that these custom actions can be launched only at the end of the installation. Launch Conditions Editor Using this editor, you can specify conditions that must be met in order for the setup to run. If the user tries to install the application on a system that does not meet the launch condition, the setup will not run. While setting the launch condition, it is also possible for you to specify that searches be performed on the target computer in order to determine the existence of a particular file, registry key, or component. The launch conditions editor shown below provides two options that can be used to set conditions. - Search Target Machine: This option allows you to specify the kind of search that needs to be performed on the target computer. This may include search for a specific file, registry key, and so on.
- Launch Conditions: This option allows you to check for the presence of specific applications such as IIS (Internet Information Server), .NET Framework, and so forth in the target computer.
The following table provides the list of the possible launch conditions that can be specified through the Launch conditions editor. Conditions that can be set through the Launch Conditions Editor | Condition | Purpose | | File Launch | Used to search for installed files on the target system | | Registry Launch Installation | To search for registry keys before the start of the installation | | Windows Installer Launch | To search for the Windows installer files | | .NET Framework Launch | To check for the existence of the .NET Framework on the target computer | | Internet Information Services Launch | To check for the installed version of IIS |
Checking for the existence of the .NET Framework on the target machine
For the purpose of this article, let us add support to check for the existence of the .NET Framework on the target machine during the installation process. Select View -> Editor -> Launch Conditions from the menu. In the Launch Conditions Editor, select Requirements on Target Machine node and select Action -> Add .NET Framework Launch Condition from the menu. Now that you have set the .NET Framework launch condition, a user who tries to run the installation without having the .NET Framework installed will receive a message saying that the .NET Framework needs to be installed on the machine before proceeding with the installation. User Interface Editor As the name suggests, this editor permits you to specify the sequence of user interface dialogs that will be displayed during the installation of application on the target computer. 
As shown in the above figure, the User Interface Editor consists of two high-level installation modes. - Install: The install section lists all the dialog boxes that will be displayed when the end user runs the installer.
- Administrative Install: This section lists all the dialog boxes that will be displayed when a system administrator uploads the installer to a network location.
The pre-defined dialog boxes in the Install and Admin sections can be further sub-divided into the following three categories. - Start dialog boxes: The dialog boxes in this category are displayed before the installation begins.
- Progress dialog box: This dialog box allows you to provide the users with the feedback on the progress of installation.
- Finish dialog boxes: This dialog box displays that the installation is successfully completed. It can also be used to allow the users to launch the application.
It is very easy to rearrange the user interface dialog boxes by dragging and dropping them onto proper locations. The default set of dialog boxes shown in the above picture will always show up in the installation sequence of the application even if you have not configured these dialog boxes. Adding Splash dialog to the installation sequence
Using the User Interface Editor, you can also insert additional dialogs to the installation sequence by selecting Start dialog box from the user interface editor and then selecting Action->Add Dialog from the menu. In the Add Dialog window, select Splash dialog from the list. Once the Splash dialog is added to the user interface editor, you can then drag and drop dialogs to arrange them in the proper sequence. Since the Splash dialog is always displayed in the beginning of the installation, move the Splash dialog to the beginning of the sequence. In the splash dialog, you can also display a bitmap. To add a bitmap to the Splash screen, right click on it and select Properties. In the Properties window, set the SplashBitMap property to a specific bitmap file path. Similar to the Splash dialog box, there are a number of pre-defined dialog boxes such as License Agreement, Read Me, Register User, Customer Information and so on that you can add to the installation sequence from the Add Dialog option. The following screenshot shows the various options available in the Add Dialog box. 
Deploy IIS Settings An important issue you need to consider when planning for deploying ASP.NET applications is how to deploy IIS settings along with your solution. If you choose to deploy your Web application with copy operations, such as XCOPY, Windows Explorer, or FTP operations, IIS settings are not included with that deployment. You will need to apply IIS settings separately. You can either do this manually or write IIS scripts for applying the settings to the Web folder. If you use the Visual Studio .NET Copy Project command, a new virtual directory is created for you on the target Web server. However, the IIS settings are not copied to the new virtual directory on the target server. The new virtual directory inherits the default settings from the Web site. Again, you need to apply the appropriate IIS settings separately. If you package your ASP.NET application in a Windows installer Web setup project, you can specify that certain IIS settings be applied when your solution is installed. To configure virtual directory settings, select the Web Application Folder from the File System Editor. Select Properties from the menu. The following figure shows the Properties window. 
Some of the important properties that can be configured through this dialog box are: - AllowDirectoryBrowsing: This property allows you to configure the IIS Directory browsing property for the selected folder. This setting corresponds to the Directory browsing check box on the Directory page of the Internet Information Services Web Site Properties dialog box and can be set to either True or False.
- AllowReadAccess: This property sets the IIS Read property for the selected folder. It can be set to either True or False.
- AllowScriptSourceAccess: This property sets the IIS Script source access property for the selected folder.
- AllowWriteAccess: This property sets the IIS Write property for the selected folder.
- ApplicationProtection: This property sets the IIS Application Protection property for the selected folder. It can be set to any one of the following values: vsdapLow, vsdapMedium, or vsdapHigh.
- AppMappings: This property sets the IIS Application Mappings property for the selected folder.
Specifying additional IIS Propeties There are some IIS settings that cannot be set with properties of your Web setup project. These include specifying directory security settings (for anonymous access, basic authentication, or Windows authentication) and specifying custom errors. However, you can overcome this problem by considering alternative approaches. One useful approach would be to include custom actions in your Windows installer file. As mentioned before, using custom actions, you can run code at the end of an installation to perform actions that cannot be handled during installation. The code can be in the form of a DLL, executable file, script, or assembly. These custom actions need to be configured using the Custom Actions Editor that can be accessed through the menu View -> Editor -> Custom Actions. Installing the ASP.NET Web Application Once you have created the Windows installer file (.msi file), then installing the ASP.NET application on the target servers is very straightforward. All you need to do is to double-click on the .msi file from the Windows explorer. This will initiate the setup wizard, which will walk you through the installation steps. After installing the application, you can see the ASP.NET application in the Start -> Settings -> Control Panel -> Add/Remove Programs in your computer. From here, you can run the setup program to uninstall the application any time you want to do so. Visual Studio .NET Setup Projects Vs Other Deployment Options As explained before, we can deploy the Web application using any one of the following options: - XCOPY or Copy Project option in Visual Studio .NET
- Visual Studio .NET Web Setup Project.
As with any technology, there are limitations as to how and when you should use XCOPY and Copy Project options to deploy .NET-built applications. Typically, they are only useful in deployment scenarios that are simple and manually executed. They can also be ideal for on-the-fly updates. There are some situations where XCOPY would not suffice; these would require a more robust deployment method. The following list highlights some situations where you need a sophisticated installation method. - If you are automating deployment of COM components (that are used by the .NET applications), you need to register the COM components as part of the installation.
- If you need to pre-compile an assembly to native code on the remote computer.
- If you need to install assemblies into the remote computer's Global Assembly Cache (GAC).
- If you are installing an application as a Windows Service.
- If you are looking to create desktop shortcuts, add an icon to Add/Remove Programs panel, and create start menu entries, and so on.
In the above situations, you need to employ a more robust deployment solution, which is provided by Visual Studio .NET installer. Furthermore, in many cases, the final deployment solution is targeted towards end users who lack the necessary skills to manually configure an application. By providing an easy-to-use interface, the Visual Studio .NET installer automates most of the functionalities performed during the installation. On top of that, the Visual Studio .NET installer technology provides the following benefits. - When you install an application, entire information about the application is recorded in a Windows installer database. When the application is uninstalled, the database is checked to make sure that no other applications rely on its components before removing it, thereby avoiding the infamous DLL hell problem.
- If there is a failure during the installation, you can perform a clean rollback removing all the dependencies from the system.
Conclusion In this series of articles, we have seen how to deploy an ASP.NET Web application using different types of deployment mechanisms such as XCOPY, Copy Project option in Visual Studio .NET, and Visual Studio .NET Web Setup Project. We also covered what approach to use in what situations by highlighting the advantages of one approach over another. I hope you find this article useful and thanks for reading. About the Author Thiru has almost six years of experience in architecting, designing, developing and implementing applications using Object Oriented Application development methodologies. He also possesses a thorough understanding of software life cycle (design, development and testing). He is an expert with ASP.NET, .NET Framework, Visual C#.NET, Visual Basic.NET, ADO.NET, XML Web Services and .NET Remoting and holds MCAD for .NET, MCSD and MCP certifications. Thiru has authored numerous books and articles. He can be reached at thiruthangarathinam@yahoo.com.
|
