I chose a standard Windows Installer deployment because I thought it would match more closely with the needs of the typical Library system user. The Library application is meant to be a permanent feature on the target workstation, so it's likely that someone with IT knowledge or administrative privileges will perform the actual installation. As a licensed product, there is little chance that I would be putting copies of the Library installation out on my public web site. A CD distributioncommon for MSI installationsis the expected medium. Also, because it's a quality piece of software from a trusted vendor (that's me), there isn't a need for a protective sandbox. Still, the application does include several files, including two online help files, so an XCopy installation would be a burden. All in all, a standard MSI installation is the best deployment plan.
Planning the Deployment
The Setup Wizard automatically adds my project assembly to the MSI file, but I am sure there are other files needed to properly deploy the Library Project. A quick look through the previous chapters reveals the following list of file requirements:
The generated Setup file will include only the first four items in that list (three if you are excluding the font), and the first two are added automatically by the Setup Wizard. This won't be too difficult.
Building the Setup Project
Earlier in the chapter, we added a new Setup project to an existing project, combining them into a single solution. It is possible to build a Setup project that appears alone within Visual Studio. In such projects, you need to browse for the target assembly (release\Library.exe) to include it in the Setup output. However, the Setup Wizard doesn't do much for you if you go that route. So for the Library project, let's add a new Setup project to a Library project already loaded into Visual Studio.
Load the "Chapter 23 (After) Code" project, either through the New Project templates, or by accessing the project directly from the installation directory. Then save the project to a folder where you want to build the complete Setup solution. I have also included a "Chapter 24" folder in the installation directory, but not as a project template. This folder already contains a linked Setup project. If you want to view this finished solution, open the Library.sln file in the "Chapter 24" folder.
The first few steps parallel those we performed earlier in the chapter. Once you have the Library project loaded and saved to its target folder, add a new Setup project using the File Add New Project menu command. Select "Setup Wizard" as the template, enter "LibrarySetup" for the Name, and use the just-saved Library project's folder as the Location. Apply the following settings within the wizard.
Complete the wizard and use the File Save All menu command. When prompted to save the solution file (Library.sln), just store it in the Library project directory, which should already be selected.
As before, the Setup project opens to the File System Editor. Before making any changes within the editor, let's set some Setup-wide properties. Click on "LibrarySetup" in the Solution Explorer panel, and modify the following properties in the Properties panel.
Because the File System Editor is open, let's make a few changes there. When we added the Library.exe assembly through the wizard, it figured out all of the required dependencies. Not only do the main program and help file items appear in the "Application Folder" section, but three additional DLLs appear, all used to run the library reports (see Figure 24-9).
Figure 24-9. A lot more files than we bargained for
Because these three DLLs are supplied by Microsoft as part of .NET, it doesn't make much sense to store them in my own application's installation directory. They should go in the Global Assembly Cache, the special system folder that maintains shared .NET assemblies. The Global Assembly Cache isn't one of the folder choices displayed in the editor, but it can be. Make sure that the left-hand panel of the File System Editor is selected (the one with "File System on Target Machine"), and then use the Action Add Special Folder Global Assembly Cache Folder menu command. A new folder, "Global Assembly Cache Folder," appears in the left-side panel. Select the "Application Folder" item again, and then drag the three DLL items into the new Global Assembly Cache Folder item, as shown in Figure 24-10.
Figure 24-10. Make the three DLL files someone else's responsibility
Let's add two shortcuts to the user's system during installation: one on the desktop and one in the Start menu's Programs section. Both shortcuts point to the main Library.exe assembly. The Setup wizard anticipated our needs to adding the "User's Desktop" and "User's Program Menu" folders to the File System Editor. All we have to do is add a shortcut to each folder.
Let's start with the desktop. Select the "User's Desktop" folder, and then right-click in the right-side panel (where the files would appear). From the context menu, choose the Create New Shortcut menu command. (This same command is available from the main Action menu when the right-side panel is active.) The Select Item in Project dialog, shown in Figure 24-11, appears. Browse into the "Application Folder" item and select "Primary Output from Library (Active)." The new shortcut appears in the right-side panel, waiting for you to give it a more meaningful name. Give it the name "ACME Library."
Figure 24-11. Adding a new shortcut to a target file system folder
To create the same shortcut in the Start menu, follow all the steps in the previous paragraph, but start from the "User's Programs Menu" folder instead of the "User's Desktop" folder.
Adding those shortcuts was a good idea, but whenever I install new software, I always immediately delete any shortcut that was added to the desktop. Adding an icon to the Start menu's Programs folder makes sense, but I like keeping a nice, clean desktop. Laugh if you want, but keeping that desktop free from clutter is what helps make me a world-famous author and developer.
What we need is a way to alter the behavior of the Setup program so that it doesn't create the desktop icon if the user doesn't want one. The Setup project provides a way to do this. First, we need to add a prompt where the user indicates a desktop-icon preference, and then we need to act on that preference. The first step involves altering the user interface of the Setup program. Such changes occur through the User Interface Editor. Display this editor with the View Editor User Interface menu command. The User Interface Editor appears in Figure 24-12.
Figure 24-12. The user interface editor displays each dialog and each prompt
The User Interface is divided into two main installation types: "Install" and "Administrative Install." The administrative branch is only used when an administrator wants to store the setup image on a shared network folder. It doesn't allow the type of changes we want to make. So let's focus on the standard "Install" branch, which manages standard user installations on a client workstation. Both branches include step-by-step prompts that appear to the user during the setup process. Custom data collection prompts can only be added to the "Start" entry in the "Install" main branch.
During actual setup, the user interface prompts the user in a wizard-like fashion. During the initial "Start" phase, the Setup program collects the user's desires for the remainder of the process. Once this section completes, installation proceeds until it completes or fails. What we want to do is insert a new step in the wizard process, displaying a checkbox to the user that asks whether the desktop icon should appear or not. Additional data collection fields like these are added through new "dialogs." And there just happens to be a dialog that includes a customizable checkbox. In the "Install" branch, right-click on the "Start" item, and select Add Dialog from the context menu. The Add Dialog window, shown in Figure 24-13, displays the available dialogs. Select the "Checkboxes (A)" item from the list and click OK.
Figure 24-13. There are a few different dialog options available for setup customization
The new "Checkboxes (A)" item appears in the "Install/Start" section. Use the mouse to drag it up until it appears between the "Welcome" and "Installation Folders" dialogs. The Checkboxes dialog lets you display up to four checkbox selections with custom captions. Make sure it is selected in the dialog outline, and then use the Properties panel to set this new dialog's properties:
During the setup process, the user sees the new dialog prompt in Figure 24-14. It includes the banner text, the body text, and the single checkbox as configured in the custom dialog's properties.
Figure 24-14. The sparse but useful checkbox dialog in action
Now it's time to use that checkbox setting. Close the User Interface Editor and return to the File System Editor. Select the "User's Desktop" folder in the left-side panel; then go to the Properties panel. One of the few listed properties is Condition, which lets you define a Boolean condition that, when true, installs the associated files on the user's desktop. However, if the condition is false, no associated files will be placed on the user's desktop during installation. Set this property to the following text.
This is the name we gave to the first checkbox back in the dialog design. During installation, the setup program checks the user's selection, and alters the desktop update as requested.
One thing I won't be adding to my version of the Setup program is the barcode font. Sadly, I have not acquired a license to distribute a third-party font to you or anyone else reading this book. The good news is that I just saved you $10 on the cost of the book. The bad news is that I will have to tell you how to add the font, but not actually do it.
Actually, you can probably already guess how to do it. The "Fonts" folder is one of the special folders available in the File System Editor. When the left-side panel is active, use the Action Add Special Folder Fonts Folder menu command. Then add the original font file (a TrueType ".ttf" file) to the "Fonts" folder section. You won't be able to add this font directly from your Windows\Fonts folder. Instead, you will need to get the original ".ttf" file and use that. On the target workstation, the setup program properly installs and registers the font for use in Windows.
The Setup project is complete. The only thing left to do is to generate the MSI file. You might have noticed a new control in the main Visual Studio toolbar that appeared when we added the Setup project to the solution. Figure 24-15 shows this "Solution Configurations" drop-down list at the right end of the main toolbar.
Figure 24-15. The Solution Configurations selector in the toolbar
This control is part of the Configuration Management system built into Visual Studio. It lets you set up different compilation and release scenarios for internal and public use. By default, Visual Studio always creates a "Debug" and "Release" configuration for you. The Debug configuration includes the necessary files and components that enable full debugging of your application. These extras are, of course, missing from the Release configuration. Normally, you use the Release configuration when building your Setup project because you don't want your customer poking around in the debuggable source code. Now would be a great time to choose "Release" from this tool.
It's time to build the MSI file. Right-click on the "LibrarySetup" root in the Solution Explorer panel, and select Build from the context menu. In just a few seconds, your MSI file will be baked and ready to eat. You'll find it in the Setup project's Release subdirectory. This directory also includes a Setup.exe file that acts as a bootstrapper. Any workstation with the Windows Installer system present will work with just the plain MSI file, but providing a Setup.exe file may add a level of comfort to novice users.
The Distribution Media
I hate it when users come over to my office and try to copy the MSI file directly from my hard drive. I find that providing the file on a CD tends to improve the vendor-customer relationship. So let's build a CD for client use.
The distribution CD contains all of the content needed by the library IT staff to support the application. It contains distinct directories for each type of content. Here's what I am planning to put in the root of the CD.
I've put all these directories and their files in the book's installation directory, in a subdirectory named Library CD Contents.
The Readme.htm file contains the following administrator-friendly content.
I want this file to appear automatically when the user inserts the CD into the workstation drive. This requires one additional file named "autorun.inf" at the root of the CD. This simple INI-style file supports the Auto Run feature used by Windows CDs. Here is the content of the file that will display the Readme.htm file automatically.
[Autorun] Open=explorer.exe Readme.htm
Copying all of these directories and files to a CD and adding a pretty label should result in a happy librarian.
We're quickly approaching the end of the book. Only one chapter remains. Turn the page to find out what exciting content you'll find there.