Professional Documents
Culture Documents
Yesterday 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
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.
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.
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 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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.