Deploying Windows Forms ApplicationsYesterday you learned how to create Windows Forms applications. Today, you learn how to create a setup project that deploys a Windows Forms application to an end user's machine. If you're familiar with the Setup project type in Visual Basic 6, you'll be shocked and amazed at how easy and reliable it is to create setup projects in .NET. Today, you learn how to Create a Windows Installer package using Visual Studio .NET Create custom setup actions in installer packages Create a license agreement custom dialog Deploy the .NET Framework with your application

Introduction to Application DeploymentDeploying an application always seems like it's such a simple process to an end user. All the end user needs to do is double-click Setup.exe and the program he's trying to install works like magic and installs the files needed for the application. As a developer, you know that creating deployment projects with the tools provided by Microsoft has been a nightmare. Using Visual Basic 6 Setup and Deployment Wizard to deploy forms-based applications was a frightening thought. When an installation was complete on a target machine, you had to cross your fingers, and pray that when the machine rebooted there would be no blue screen of death, and that some core operating system file would not be accidentally overwritten by your installation package. This opened up the market for third-party deployment applications, for which most companies simply give in and pay big dollars. With the advent of Visual Studio .NET, there are no longer issues with deploying applications using the tools provided by Microsoft. It's easy to understand why deploying applications was so difficult before .NET. All components and applications on a machine needed to be registered in the Windows Registry. Any time the Registry is involved, there are going to be complications. With .NET, the Registry goes away. There's no need to register an application or component to make it work. The .NET Framework provides the runtime that all .NET applications need to run. So, if the .NET Framework is installed on the machine, your application runs without needing any extra handling.

This is a huge feature of .NET. The fact that you can literally copy a folder that contains an application from machine A to machine B, and just be able to run, saves a lot of configuration and deployment headaches. In addition to the core technology in .NET making the deployment of applications a snap, the actual installation technology has improved as the operating systems have improved. The Windows Installer technology is responsible for handling installation services in Windows. Windows Installer files have an .msi extension. When I refer to an MSI package, it's the same as a Windows Installer file.

Introduction to the Microsoft Windows Installer ServiceThe Windows Installer is the technology behind handling all setup and deployment in Windows Me, Windows XP, Windows 2000, and Windows .NET Server. Windows Installer packages can also run on earlier versions of Windows, but the technology is built into the newer Windows version. Windows Installer packages are predefined databases that contain information about what must be installed on a deployment target. Whereas the Visual Basic 6 Setup and Deployment Wizard used script files to determine the order of each component and files that needed to be installed, a Windows Installer package contains information about what must be installed, not how it should be installed. The Installer service keeps track of every application that's installed on a computer, allowing you to uninstall, repair, or reinstall a package based on the state of the machine. This also gives you the ability to roll back installations. For example, if an installation is at 90% and the installation is canceled, all changes made to the computer are rolled back. The installation is not left in a flux state. Using the tools in Visual Studio .NET, you can create Windows Installer packages that set properties and conditions, create custom dialogs, handle user preference input, and even include a product registration with the installation package. If your organization uses Windows 2000 Server or Windows .NET Server, a technology called Group Policy is built into Active Directory. Using Group Policy, an administrator can define what Windows Installer packages each client machine should have, and the setup is automatic when a user logs in to her machine. This is taken to the next level with Active Directory. If you delete a file that was installed, and attempt to launch the application's executable, the Windows Installer service verifies that the file exists on the client machine. If it doesn't, it's retrieved from the server. You can also update version information on

assemblies and the Windows Installer server always checks for new versions on the server. Using Microsoft Servers and Windows Installer provides a bulletproof mechanism for keeping applications current and working.

Understanding the Deployment Projects TemplatesVisual Studio .NET provides templates for creating deployment projects. In the New Project dialog, there is a Deployment Projects node that contains the available templates for creating deployment projects. Figure 4.1 displays the Deployment Projects node of the New Project dialog.

The Deployment Projects node in Visual Studio .NET. The following is a list of deployment project types: Setup Project Creates an empty setup project that you can customize. Web Setup Project Creates a setup project with options set for deploying Web applications. You learn about this project type on Day 6, "Deploying ASP.NET Applications." Merge Module Project Creates a merge module, which normally contains applications assemblies. Merge modules are a major feature in Windows Installer, and you'll learn how to implement a merge module later today. Setup Wizard A basic wizard that enables you to choose deployment options for a project. Cab Project Creates Internet-deployable cabinet (CAB) files.

Creating a Windows Installer PackageThe easiest way to create a new MSI package is from an existing application. To see this work, you need to create a new Windows Forms project. Open Visual Studio .NET, create a new Windows Forms Application project, and name it InstallerTest as shown in Figure 4.2.

Creating the InstallerTest application. After the project is created, you can add a deployment template to your solution. To do so, right-click the InstallerTest solution name in the Solution Explorer, and select Add, Add New Project from the contextual menu. When the New Project dialog pops up, select the Setup and Deployment Projects node, and then Setup Project. Change the name to InstallerTestSetup as shown inFigure 4.3, and click the OK button to add the new project to your solution.

Adding a new setup project to your solution. After the new project is created, your Solution Explorer and main window should look like

Figure 4.4.

The InstallerTest solution after adding a setup project. You're now looking at the interface that you'll use to create the MSI package. Everything that you need to create the setup project can be done with this designer, which is known as the File System Editor (FSE). Using the FSE, you create virtual objects that are stored in the MSI package you create. During the installation of your MSI package, the files and directories created using the FSE are created on the target machine. The navigation of the FSE is the same as using Windows Explorer: The left pane contains the

hierarchy of the directory, and the right pane contains the details. Each item in both panes has a contextual menu that pops up with a right-click, giving you action options to perform, such as creating directories, adding files, creating shortcuts, and specifying build options.

Setting Properties on the Installer PackageThe next step is to set properties on the installation project. To do so, select the InstallerTestSetup project name in the Solution Explorer, and press the F4 key to get to the Properties window. The properties you set here define what information is displayed in dialogs during the setup, and what information is displayed in the Add/Remove Programs applet of Control Panel. Figure 4.5shows the Properties window after I customized it with my own information. Do the same to your properties.

Setting properties in the InstallerTestSetup project.

Adding the Application Output to the Installer PackageNow that some properties are set, you must tell the Installer project what the primary output is to install. In this case, it's your InstallerTest Windows Forms project. Note that the project wasn't automatically added when you added the deployment project to your solution. You must always add the files to be installed. To add the InstallerTest application to this installer package, right-click on Application Folder on the File System Editor. From the contextual menu, select Add, Project Output, as Figure 4.6 demonstrates.

The Add Project Output menu selection. When you select the Add Project Output option, you're prompted with the Add Project Output Group dialog, as Figure

4.7 shows

The Add Project Output Group dialog. By default, the active project in the solution is in the Project drop-down list. Click the OK button on the Add Project Output Group dialog box to add the InstallerTest application to this setup package. At this point, the primary output has been added to the InstallerTestSetup project. Your application should look like Figure

4.8.

Solution after adding the primary output. If you right-click on the primary output in the right pane of the File System Editor, you can see the available options for the output assembly. From the contextual menu, click the Create Shortcut menu item. Change the shortcut name to Installer Test. Your File System Editor should now look like

Figure

4.9.

File System Editor after creating a shortcut for the primary output. After you create the shortcut, you can drag it to the folders in the left pane of the File System Editor. Anything you add to the folders, be it a file, shortcut, or anything, will be added during the installation.

Remember that the File System Editor is a virtual view of the target machine. Drag the shortcut to the User's Desktop node in the left pane. If you right-click the shortcut, and select Properties from the contextual menu, you'll see some of the available properties that you can set. Change the Description property to My First Test Of Installing, as Figure 4.10 demonstrates.

Setting properties on a shortcut.

Creating Custom ActionsOne of the key features that deployment projects offer is the ability to create custom actions for your installation package. Some of the features are Associating a file extension with your application Adding Registry keys based on user input Setting launch conditions, such as file dependencies or version requirements for dependent applications Installing custom files based on user selections during setup Creating databases or other objects programmatically Launching applications when installation is complete

To test this, you're going to create a Registry key and a version launch condition, specifying that Microsoft Word version 9.0 or greater is required by your application.

Creating a Registry KeyTo create a Registry key, click the View main menu, and then select Editor, Registry .You're now in the virtual Registry Editor. From this screen, you have complete control over what Registry keys you add to your application. Right-click the HKEY_CURRENT_USER node and select Add Key from the contextual menu. Add a key named TestKey. After the key is added, right-click on TestKey and select New, String Value from the contextual menu. Name the new string value ScreenPref. In the Properties window, change the Value property to Maximize.

After you add keys and values to the Registry, you can access them using the classes in the .NET Framework. Using the Registry Editor is a great way to set default user preferences. In your application, you can enable the user to modify the user preferences as needed.

Adding a Launch ConditionAdding a launch condition forces the installer to check for the existence of a file, application, or dependency before installation starts. In this step of setting up the test installer, you're going to make sure that Microsoft Word version 9.0 is installed on the deployment target. This is just an example of what you can do with a launch condition, but there are hundreds of reasons why this is a great feature. The following list should give you some ideas: If you're doing any Microsoft Office automation, the type libraries for Office aren't always compatible. You might specifically need the Word 9.0 type library to make sure that your Word Merge code doesn't crash.

If you depend on a specific browser version, such as Internet Explorer 5.0 or higher, you can stop the installation if that version does not exist on the machine.

If you're using a specific version of Microsoft Data Access Components ( MDAC), you can ensure that they're on the machine before installation.

If the machine doesn't have the .NET Framework installed, your application won't run, so you need a launch condition to check this.

If your application uses Active Directory, it will work only on Windows XP or greater, so you must check the OS version before installing.

To test this, select Editor, Launch Conditions from the View menu, as demonstrated in Figure 4.14.

he Launch Conditions menu selection. When the Launch Condition Editor is open, right-click on the Requirements for Target Machine node and select Add File Launch Condition, as Figure

4.15 demonstrates.

Adding a file launch condition. Take note of the other launch conditions. From this menu, you can create conditions for checking the existence of the .NET Framework, specific Registry settings, specific version launch conditions. After you add the file launch condition, a new item named Search For File1 is placed under the Search Target Machine node. If you select this item, you'll notice the Properties window appears, and you can set the conditions for the file search. Figure 4.16 demonstrates how to add version information, filename, and directory information for this search. Notice the Depthproperty is changed to 2. That means I want the installer to search two levels deep inside the Program Files folder. The more depth you specify, the longer the search will take to complete

IIS settings, and Windows Installer

Setting the Word Search launch conditions. Because I know that Word 9.0 is on my machine, my install will succeed when I test it. You should change the Word 9.0 file search to another file and set the properties accordingly if you want to attempt another search. To verify the FileName, MinVersion, and MaxVersion properties, I used my Windows Explorer to find WinWord.exe and viewed its properties, as Figure 4.17demonstrates.

Filename and version information for MS Word. To complete the version and file search for Word, you need to change the Condition1 item that was added under the Launch Conditions node when you added the file search. Condition1 has an Error property that you can set to prompt the user if the installation will fail. You can also set the Property property in the Word 9.0 Search node to a friendlier name, and use thatProperty name as the Condition property for the launch condition. Change the Error property to a useful error message based on the file you're searching for.

Using Custom Dialogs During InstallationThe Dialog Editor enables you to add custom dialog options for the installation package. These could range from simple license agreement prompts to complex installation options. To see what options are available, select Editor, User Interface from the View menu to get the Dialog Editor, as shown in Figure 4.18.

The User Interface menu selection. You can see in Figure

4.19 that the standard dialog boxes already exist in the setup package. To add

custom dialogs, you can right-click the node that you want the dialog box to appear under and select Add Dialog.

Standard dialog boxes are already added. After you select Add Dialog from the contextual menu, you are prompted with the Add Dialog dialog box, as Figure

4.20demonstrates.

The Add Dialog dialog box. From the Add Dialog dialog box, select the License Agreement dialog box. This adds the default license agreement screen to your installation. The license agreement dialog has a LicenseFile property that you can select to indicate what the license file is. This file must be a rich text format (RTF) file, and must be included with the installation. For this example, you don't need to add a license agreement, so you can just leave the LicenseFile property blank. My goal is to get you comfortable with the different available options. When you add the custom dialog, it ends up as the last dialog in the node you added it to. Because a license agreement should logically appear before the installation actually begins, you should right-click the License Agreement node, and select Move Up from the contextual menu. You can manipulate the order in which all screens appear by moving them up or down.

Building the ApplicationYou've now completed the basics in building a solid installation package. The next step is to build the MSI package. Within the Visual Studio .NET integrated development environment (IDE), select the Install

menu item from the Project menu. This enables you to test the installation as you're creating it. If you're testing different launch conditions and dialogs, using the Install and Uninstall menu items is a good idea. You're going to be brave and just build the whole solution, and test it from the command line. Before you select Build Solution from the Build menu, right-click on the TestInstallerSetup project in the Solution Explorer and select Properties from the contextual menu. Figure 4.21 is the properties dialog for the installer solution.

Build configuration properties. Notice the various configurations you can set. You can also include an Authenticode certificate for your installation. This guarantees the source of your installation if you need it to be trusted by a client machine. To build the package, select Build Solution from the Build menu. Doing so builds the TestInstaller.exe file and it createsTestInstallerSetup.msi. If you view the results of the build in the Output window, you'll notice a message that the .NET Framework is required to make this installation work. By default, the 20MB redistribution package for the .NET Framework isn't included in the output. You'll learn how to factor that in during the next section. If any errors are encountered during the build, you're notified of them through the Task Window. After the project is built, you can navigate to the folder where the MSI package was created to view the output. Figure 4.22 is where the MSI output was put on my machine.

Browsing to the setup files. You'll notice that there's an MSI package, a Setup.exe file, and two other EXE files. The files named InstMisA.exe andInstMsiW.exe are version-specific Windows Installer setup packages. When you deploy an application, the launch condition for the Windows Installer makes sure that the target machine has the correct Windows Installer version installed.

Running the MSI PackageNow you can run the MSI package you just built to view the dialogs and the behavior of the installation. So, double-click theTestInstallerSetup.msi file in the file system. The first screen you should see is shown in Figure 4.23, which welcomes you to the setup for your project.

The Welcome screen for TestInstallerSetup. If you click Next, you'll see the custom dialog box you added that makes the user select I Agree in order to continue. Figure

4.24shows the License Agreement dialog.

The custom License Agreement dialog box. Finish the installation by clicking Next for each screen you're given. These are the default dialogs that always appear unless you explicitly delete them from the Dialogs Editor. If you want an installation to occur with no user interaction, you can delete the dialogs from the Dialog Editor, and the setup will still be functional. After the setup is complete, you should have a new shortcut on your desktop for the application. If you double-click the shortcut, you should see the single form of your application pop up. Just like that, you have a complete installation package. Now open up the Control Panel, and select the Add or Remove Programs icon. If you scroll down, you'll see the Test Setup Installer as

Figure

4.25 shows.

Your application in Add or Remove Programs. If you click the hyperlink that says Click Here for Support Information, you'll see something like

Figure

4.26.

Adding Merge Modules to Your SetupMerge modules are another method of packaging a component for redistribution. The beauty of merge modules is that they're independent installation components that contain all the necessary logic to successfully install, but they can't be installed on their own. They must be part of an MSI package. Like the setup project you created earlier, you can create a merge module project with resources, dependencies, launch conditions, and custom actions. Merge modules are very useful for pre-packaging components that must be shared across multiple resources on a computer, or just as a mechanism of breaking apart a large installation. There's a Merge Module project template that you can use to create your own merge modules, or you can add a merge module to your setup project if it already exists. To find out how to add a merge module, return to the InstallerTestSetup project and get to the File System Editor by right-clicking on the project name and selecting View, File System Editor from the contextual menu. Next, select Add, Merge Module from the Project main menu. You're now prompted with the Add Module dialog that Figure 4.27displays.

he Add Modules dialog box.

In the C:\Program Files\Common Files\Merge Modules folder there are predefined merge modules for several components. Select themsmask32_X86_ENU.msm as shown in Figure 4.27. Notice that merge modules have an .msm extension. After the file is selected, it can be seen in your Solution Explorer. When you build the application, the MSMakedEdit control's merge module will be included with the MSI package, and it will install as part of your package. If the installation of the merge module fails, the complete installation fails because the merge module is part of the package. From your point of view, it's just another component to include in your deployment package.