Automate with Microsoft Windows Installer 2.0

Microsoft Windows Installer 2.0 software is integrated into VS .NET. Using this software, you can create deployment packages. Your packages will include a Windows Installer (.msi) file, a Setup.exe file, and possibly other needed files.

Note	You can use Windows Installer for both ASP.NET (Web applications and Web services) and .NET Windows applications. Both COBOL .NET and VB .NET support this "automated" approach to deployment.

To learn how to use Windows Installer, you'll create a few deployment packages using the sample applications from Chapter 13. First, you'll create a deployment package for your MyFirstWinFormCobol COBOL .NET sample Windows application. Next , you'll create a deployment package for your WebApplicationSampleCobol COBOL .NET sample ASP.NET application.

Note	You will also use the MyFirstWinFormVB VB .NET sample Windows application and WebApplicationSampleVB VB .NET sample ASP.NET application. It will be helpful to note any differences you experience between the two language implementations while you attempt to build deployment packages.

When you create deployment packages using Windows Installer, the basic approach is to open your application solution where you have one or more projects. Then, add a deployment project to your application solution. Finally, you "add" the files that make up your application project to the deployment project.

In the following sections you'll learn how to create deployment packages using Windows Installer and VS .NET.

Creating a Deployment Package for a Windows Application

Start by opening the MyFirstWinFormCobol.sln sample application in your VS .NET IDE. Next, follow these steps:

Add a deployment project to your application solution. From the Standard toolbar, select File Add Project New Project (see Figure 17-8).

Figure 17-8: Preparing to add a deployment project to your existing solution
In the Add New Project window, open the Setup and Deployment Projects Project Types folder. Choose the Setup Project template. For this demonstration, change the default name of the new project from Setup# to MyFirstWinFormCobolSetup . When you've finished, click OK (see Figure 17-9). Optionally, you can use the Setup Wizard template. ^[6]

Figure 17-9: Choosing the Setup Project template
Notice the File System Editor in the VS .NET IDE. Also, notice that the Solution Explorer window shows the addition of the new setup project (see Figure 17-10).

Figure 17-10: The VS .NET IDE showing the File System Editor and the updated Solution Explorer display
Add the application project output to the new setup project. In the File System Editor window, right-click the Application Folder node. As shown in Figure 17-11, from the context menu choose Add Project Output. Optionally, select Action Add Project Output from the Standard toolbar.

Figure 17-11: Adding application project output to the setup project
In the Add Project Output Group dialog box, choose the application project from the Project drop-down list. Leave the default of Active in the Configuration drop-down box, or select Debug or Release as appropriate. As shown in Figure 17-12, the sample demonstration only shows one choice. Click OK.

Figure 17-12: The Add Project Output Group dialog box
Build your setup project. From the Standard toolbar, select Build Build MyFirstWinFormCobolSetup . As shown in Figure 17-13, your VS .NET IDE Output window will provide information indicating the success (or failure) of your build.

Figure 17-13: The VS .NET IDE Output window. Notice the messages showing that the Setup.exe and MyFirstWinFormCobolSetup.msi files were created.

Test the setup project. From your open VS .NET IDE, select the new setup project. From the Standard toolbar, select Project Install (see Figure 17-14).

click to expand
Figure 17-14: Testing the setup project

Note	The Install option will only appear under the Project menu when the setup project in Solution Explorer is highlighted.

Tip

Usually, you will not want to leave your application installed, especially if you were just testing the setup project. This will give you a good opportunity to also test your ability to "uninstall" your application. To accomplish this in VS .NET, first make sure the setup project is highlighted in Solution Explorer. Then, select Project Uninstall. Optionally, you use the Windows Add or Remove Programs feature, which you access from the Control Panel, to install or uninstall your .NET Windows application.

Notice the files are created for you within your setup project folder (see Figure 17-15). You will want to distribute this entire folder. You can use the Setup.exe file to initiate the installation.

click to expand
Figure 17-15: The setup project folder and contents to be distributed

Note

Keep in mind that if the machine you are targeting for installation does not already have the Microsoft .NET Framework or Fujitsu NetCOBOL for .NET product installed, a redistribution of software modules may be needed. Either way, you can accomplish this through your Microsoft Windows Installer package.

Add a Shortcut to Your Windows Application

If you want, you can add a shortcut to your installation setup package from either your user 's desktop or the Programs menu. To do this, simply select the output created in your File System Editor's Application Folder. Then follow these steps:

Access the context menu. Right-click the Application Folder output node (see Figure 17-16). Optionally, you can select Action Add Project Output from the Standard toolbar to initiate the process rather than right- clicking and selecting from the context menu.

Figure 17-16: Creating a shortcut to your user's desktop or Programs menu
Select Create Shortcut to Built from MyFirstWinFormCobol. Choose an appropriate name for your shortcut.
Drag the renamed shortcut from your File System Editor's Application Folder to either the File System Editor's User's Desktop folder or the User's Programs Menu folder.
Rebuild your Setup project. From the Standard toolbar, select Build Build MyFirstWinFormCobolSetup.

The steps detailed in this section and the previous section are sufficient to install a .NET Windows application. In both demonstrations , a project written in COBOL .NET was used. Although the steps to install a VB .NET Windows appli cation are basically the same, I have a few noteworthy differences to share in the following section. Given your bilingual approach, this information should be of value.

Noted Differences for Your VB .NET Windows Application

Using the MyFirstWinFormVB sample application, I began by following the same "deployment setup" steps performed in the earlier COBOL .NET sample. In the VS .NET environment, I opened the MyFirstWinFormVB VB .NET project and added a new project using the Setup Project template. From that point, I noticed the following few differences:

The Add Project Output Group window provides choices that appear to offer a more granular level of setup customization. As shown in Figure 17-17, I used the Primary output choice to complete this step of the setup process. The COBOL .NET project did not offer this level of flexibility ”the Add Project Output Group window showed only the Built choice.

Figure 17-17: The Add Project Output Group window for a VB .NET Windows application
The Dependencies window provides a meaningful display. It shows the additional files/assemblies that Windows Installer has detected and flagged as a dependency for your deployment. In the VB .NET project, you can easily access the Dependencies window. While you have the Setup project selected, simply select Action Dependencies from the Standard toolbar (see Figure 17-18). Unfortunately, this Dependencies window is sort of hidden in the COBOL .NET project.

Figure 17-18: The Dependencies window for a VB .NET Windows application
To "locate" the Dependencies window in COBOL .NET, you need to go through a few extra steps. Start by accessing the Properties window of the Application Folder output file. Then, skip over the first Dependencies property that you see. Navigate to the KeyOutput property and open the node. Select the Dependencies property from within the KeyOutput property (see Figure 17-19).

Figure 17-19: The Dependencies window for a COBOL .NET Windows application

These are simply observations. Depending on your need for these features, the differences may or may not impact your eventual deployment. Using the sample applications, I was able to successfully create a Windows Installer setup project in both VB .NET and COBOL .NET.

Two additional treats were provided by the VB .NET implementation in the Output window and in the Add New Project window. You'll now take a closer look at these last two noted observations.

The following helpful message in the Output window reminded me that the .NET Framework needs to be redistributed. The message also included instructions regarding the steps to take. This proved to be extremely helpful.

 . . . WARNING: This setup does not contain the .NET Framework which must be installed  on the target machine by running dotnetfx.exe before this setup will install. You  can find dotnetfx.exe on the Visual Studio .NET 'Windows Components Update'  media. Dotnetfx.exe can be redistributed with your setup. . . .

As you know, the preceding helpful message is not shown in the Output window when you use COBOL .NET. No big deal, right? I just think that maybe Fujitsu might use this as an example to enhance their NetCOBOL for .NET product. Perhaps they could display not only the .NET Framework message, but also a helpful message regarding the need to redistribute the required NetCOBOL runtime files.

To finish off this series of "VB .NET versus COBOL .NET" deployment- related observations, let's briefly visit the topic of the Setup Wizard template.

You may recall that one of the first steps you took for deployment project setup was choosing a template from the VS .NET Add New Project window. I wanted to try out a few of the template choices, so the Setup Wizard template choice caught my attention. As shown in Figure 17-20, the Setup Wizard option is one choice out of five.

Figure 17-20: The VS .NET Add New Project window with the Setup Wizard template choice highlighted

When I tested out the Setup Wizard template using VB .NET, my impression was that it is simple and basic but useful. I can see that this is a productivity feature, a real time-saver. With that in mind, I then wanted to try the Setup Wizard template with the COBOL .NET sample application. As shown in Figure 17-21, apparently the Fujitsu NetCOBOL for .NET product does not support this VS .NET feature.

Figure 17-21: The message I received when attempting to use the Setup Wizard template in a COBOL .NET project (Windows and/or ASP.NET)

Note

I recently contacted Fujitsu's tech support regarding their level of support for a few of the VS .NET setup features. Basically, I decided to provide feedback on my experience of using their product. Because they've always expressed appreciation for such feedback, I'm convinced that the few "areas for improvement" that I've mentioned to them have made it onto a "wish list." Beyond that, Fujitsu's tech support has indicated that future releases of Fujitsu's NetCOBOL for .NET product will likely improve on their already exceptional VS .NET setup/ deployment implementation. On that note, I'd like to acknowledge Fujitsu for providing adequate support in VS .NET to use the most essential features of Microsoft's Windows Installer. At the same time, I do feel that pointing out the few "areas for improvement" to them (which I've done) will prove to be helpful. I encourage you to contact Fujitsu's tech support and let them know how important or unimportant any of these Windows Installer features (e.g., the Add Project Output Group window and the VS .NET Setup Wizard template) are to you.

So far, you've looked only at .NET Windows applications. Now you'll turn to ASP.NET. Although it's similar to Windows applications, the deployment process for ASP.NET applications introduces additional learning opportunities.

In the next section, I demonstrate the process of setting up a deployment project targeting a Web server. As you'll see, there are a few differences between setup projects that target a Web server versus those that support Windows-type applications (stand-alone servers or individual workstations).

Creating a Deployment Package for an ASP.NET Application

Begin by opening the WebApplicationSampleCobol.sln COBOL .NET sample application (this was the sample application you created in Chapter 13). Now, in the VS .NET IDE environment, you'll perform the same beginning steps you did in the earlier section "Creating a Deployment Package for a Windows Application." In other words, you'll go to the Standard toolbar and select File Add Project New Project.

From this point forward for ASP.NET, the process changes slightly. Perform the following steps:

As shown in Figure 17-22, you'll choose the Web Setup Project template (instead of the Setup Project template that you used for the Windows application). Click OK on the Add New Project window.

Figure 17-22: Choosing Web Setup Project from the Add New Project window. The new project will be named WebApplicationSampleCobolSetup.
You'll be taken to the File System Editor in the VS .NET IDE. This view is similar to the one you saw before for the Windows application. However, this time you'll want to right-click the bin subfolder ^[7] underneath the Web Application Folder node (see Figure 17-23).

Figure 17-23: The bin subfolder underneath the Web Application Folder node in the File System Editor
Choose Add Project Output. Optionally, from the Standard toolbar you can choose Action Add Project Output. Follow the prompts to complete this step.
Add the content files. In the VS .NET IDE File System Editor, right-click the Web Application Folder node . Then choose Add File. Optionally, from the Standard toolbar you can choose Action Add File (see Figure 17-24).

Figure 17-24: Adding the content files
Navigate to your application folder. In the Add Files window, select all of the content files. You can use the Ctrl or Shift key to select multiple files (see Figure 17-25). Click Open.

Figure 17-25: The Add Files window with all content files selected
Review your VS .NET File System Editor window and your VS .NET Solution Explorer window. As shown in Figure 17-26, the appropriate files have been added to the to the application folder belonging to the Web Setup project.

Figure 17-26: The content files have been added to the Web setup project.
Begin IIS properties configuration. In the VS .NET IDE File System Editor, right-click the Web Application Folder to access the Properties window.
Continue IIS properties configuration. As shown in Figure 17-27, for demonstration purposes, you'll edit the VirtualDirectory property in the Properties window. Notice that the default value is set to the name of the Web setup project (WebApplicationSampleCobolSetup). You'll change the value to MyVirtualHome .

Figure 17-27: Using the VS .NET IDE File System Editor to change the VirtualDirectory property and the DefaultDocument property in the Properties window
Complete IIS properties configuration. As shown in Figure 17-27, you'll edit the DefaultDocument property in the Properties window. Notice that the default value is set to default.aspx. Change this to WebForm1.aspx . After you make this change, close the Properties window. As your needs dictate , you can use this Properties windows to configure additional IIS properties.
Build the WebApplicationSampleCobolSetup project.
Test the installation. In the VS .NET IDE Solution Explorer window, select the WebApplicationSampleCobolSetup project. From the Standard toolbar choose Project Install.
Test your ASP.NET Web application. Open your Web browser (e.g., Internet Explorer, Netscape). Type the URL value http://localhost/ MyVirtualHome into the address bar.

That completes the steps needed to create your Web setup project. You can execute this Windows Installer package (initiated by the Setup.exe file) on your local machine or the appropriate targeted machine ( assuming that the minimum software and hardware requirements are met). The entire setup project folder needs to be available for installation.

Tip	It may be that your "targeted" machine is on the other end of a "hosting" arrangement contract. You may want to check out the few free hosting alternatives offered for ASP.NET applications and XML Web services. Refer to your VS .NET Start Page for more information.

Automated? Yeah, Right!

You might ask what exactly is "automated" with this deployment approach. After all, you are required to take a great many steps to create the Web setup project. In spite of the steps needed to set up the process, it truly is automated. Really, it is. By using this automated approach, you are getting the following benefits:

The IIS configuration (virtual directory creation and default document setting) is being accomplished without your needing to use the IIS MMC.
You can use the normal Windows Add or Remove Programs feature. This is extremely helpful when you want to uninstall your application. By simply "removing" your application with one click via the Windows Add or Remove Programs feature, your IIS virtual directory and the physical files will be removed.
You can reuse your Web setup project repeatedly. In other words, create once, but install multiple times, even on multiple machines if appropriate.
You avoid introducing errors during the installation process. If you get it right the first time, it should be right every time.

All of these benefits are invaluable, even with this simple application. The more complicated your application becomes, the more valuable these (and other) benefits become.

Note	If your application is required to support unmanaged components (e.g., legacy COM DLLs) using the .NET COM Interop feature, your deployment will involve extra steps.

Any Noted Differences for Your VB .NET ASP.NET Application?

Don't worry, there are only a couple of noteworthy differences between the COBOL .NET and VB .NET implementations of the Web setup project. The following list quickly reviews those differences. Remember, these are simply observations I'm sharing with you for the purpose of expediting your retraining experience.

When I added the application project into the Web setup project, I had better results right-clicking the Web Application Folder node than the bin subfolder. Clicking the bin folder only applies to COBOL .NET.
When you add the content files in the Add Files window, a few extra files are located in the application folder (see Figure 17-28).

Figure 17-28: Adding the content files in the Add Files window for a VB .NET ASP.NET application. By the way, if this was an ASP.NET XML Web service, I would have also added the . vsdisco file.

I've covered most of the basic Microsoft Windows Installer features found in VS .NET. Speaking to the power and flexibility that this software harnesses, there remain many other features awaiting your discovery. In the next section, I point out a few of these remaining features.

Learning More About the Windows Installer in VS .NET

As you continue your retraining journey, you will find that there is yet more to learn about Windows Installer. For example, Windows Installer provides a set of editors to support further customization of the setup projects in the VS .NET IDE. This set of editors is available to both Windows applications (Setup Project tem plate) and ASP.NET applications (Web Setup Project template).

You have already learned about the File System Editor. As shown in Figure 17-29, there are five other VS .NET Windows Installer editors. Using these other Windows Installer editors, your setup projects and Web setup project can evolve from the basic and crude type (e.g., those you created in this chapter using my sample code examples) to the polished and professional type (e.g., those similar to the one Microsoft created for the installation of the .NET Framework and .NET tools).

Figure 17-29: With the setup project selected, from your VS .NET Standard toolbar you can access the Editor menu by selecting View Editor.

Optionally, you can access the selection of Windows Installer editors from the VS .NET Solution Explorer window. As shown in Figure 17-30, there is a row of icons for the editors. The first icon represents the File System Editor.

Figure 17-30: The row of icons on the Solution Explorer window used for navigating to the Windows Installer editors

As you continue to explore and learn, plan to revisit the VS .NET environment to make use of these Windows Installer editors. The references provided in the "Web Sites" subsection of the "To Learn More" section at the end of this chapter will be helpful.

Tip

Be sure to explore the Merge Module Project template found in the VS .NET Add New Project window. The Merge Module Project template is designed for component installation. Merge modules can help you organize portions of a larger setup project. Additionally, third-party software vendors will occasionally include merge modules specifically designed for their products. For example, you will find that the inclusion of a merge module in your deployment setup project is essential if your targeted application includes any Crystal Reports functionality. Crystal Decisions provides an excellent white paper detailing this requirement: http://support.crystaldecisions.com/communityCS/ TechnicalPapers/crnet_deployment.pdf .

Are you ready now to learn about the manual approach for .NET deployment? I know, you're probably asking "Why?" That's a good question. Let's continue.

^[6] Fujitsu's NetCOBOL for .NET product currently does not support the VS .NET Setup Wizard template feature. For the time being, you will not be able to use this feature in your COBOL .NET projects. Feel free to explore this feature with your VB .NET applications.

^[7] The requirement to "right-click the bin subfolder" only applies to COBOL .NET projects. When you use VB .NET, you right-click the Web Application Folder.