Deployment Considerations | COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer

Having developed on mainframe COBOL/CICS environments, you have certainly experienced various deployment scenarios. When you developed mainframe batch COBOL programs, perhaps you only needed to have your compiled load module moved from a dev/test load library (a partitioned dataset) to a production load library. In other cases, perhaps the process was more complex.

Maybe there was an elaborate process that resulted in your COBOL source being recompiled, link-edited, archived, and then copied to a production load library. Depending on the needs of your application, you would sometimes have additional concerns of defining Virtual Storage Access Method (VSAM) files and Base Generation Data Groups (GDG) files. Your deployment may have even included copying Job Control Language (JCL) members and copybooks to appro priate production libraries.

Note	Your applications that made use of a DB2 or IMS database may have had additional deployment concerns.

All this sounds familiar, right? Of course, it would only be fair to mention the additional production deployment concerns associated with a typical mainframe CICS application. As you know, your CICS BMS screen map and load module would have been moved. Then, you would have needed to follow up on tasks such as having your CICS transaction defined in the program control table (PCT), your application program defined in the processing program table (PPT), any I/O files defined in the file control table (FCT), and finally, any transient data (TD) queues defined in the destination control table (DCT).

Note	Obviously, this is a watered-down summary of mainframe deployment concerns. I do believe there is enough detail provided to make this mainframe analogy useful, though.

You have a few points to focus on before you dive into the .NET arena. To begin with, when it is time to deploy your mainframe COBOL/CICS application, you have several steps to follow. Most organizations have processes, policies, and pro cedures surrounding these deployment steps. There is a correlation between the needs of your application and the resulting steps taken to complete your pro duction deployment. Finally, a deployment done carefully and correctly will make the difference between your end user being negatively or positively impacted.

With .NET applications, there are deployment tasks, choices, and concerns as well. You will need to start thinking about several deployment design decisions. Although not presented as a complete list, the following considerations should be enough to get you started in the right direction:

Redistribute or not redistribute the .NET Framework
Redistribute or not redistribute the COBOL .NET runtime
Obfuscate or not obfuscate
Deploy the release or debug version
Precompile, batch compile, or just-in-time (JIT) compile
Use or not use the Global Assembly Cache (GAC)
Use or not use a strong name for your assembly
Deploy or not deploy multiple versions of your configuration file
Use an automated or a manual approach for installation

A long list, huh? Please keep in mind that this list is not even complete. Never theless, it does speak to the most common issues that you will want to be prepared for. In the following sections, I drill down to briefly discuss each of the previously listed topics.

Redistribute or Not Redistribute the .NET Framework

Will you need to be concerned about the redistribution of the .NET Framework? You will want to answer this question early on, as you plan for deployment. If the target deployment machine already has the .NET Framework installed, you simply need to distribute your application. Otherwise, you first need to concern yourself with the redistribution of the system-level software.

Tip	Although you will need the .NET Framework on your targeted production machine, you should not install VS .NET and other development tools onto the production machine. As far as .NET is concerned, the Framework can be installed alone.

It is expected that as newer machines host the future versions of the Windows operating system, this .NET Framework requirement will become less of a concern. For the time being, however, it is a concern. It is something for you to be aware of: Your .NET application expects to run on a machine that already has the .NET Framework installed.

Note

As long as you have a licensed version of VS .NET, you can redistribute the .NET Framework to targeted machines (per your end user license agreement). The one file (Dotnetfx.exe for v1.0) that makes up the redistributable .NET Framework is available by download from Microsoft's Web site (you can also find it on your .NET product CDs). Microsoft also provides a free download referred to as the Setup.exe Bootstrapper sample . The Setup.exe Bootstrapper sample provides guidance for executing the Dotnetfx.exe installation program as part of your deployment process.

The targeted machine (where your application will actually execute) must meet additional software and hardware requirements. Please refer to the Microsoft documentation (and the references provided at the end of this chapter) for more details on the redistributable package for the .NET Framework.

Redistribute or Not Redistribute the COBOL .NET Runtime

Throughout this text, I have acknowledged the possibility that you might decide to develop with Visual Basic .NET (VB .NET) or COBOL .NET. If you decide to go with the COBOL .NET choice, keep in mind that you will incur additional concerns when it is time to distribute your application.

As it turns out, there are additional files that you will need to (re)distribute.

These "extra" files represent the runtime needed to support Fujitsu's NetCOBOL for .NET product (or rather, COBOL .NET ”the term I have chosen as an unofficial reference).

As shown in Figure 17-1, the files are conveniently grouped in one folder.

Figure 17-1: C: \Program Files\Fujitsu NetCOBOL for .NET\Redist\Runtime

According to Fujitsu's product documentation, these "additional" files must be installed into the GAC.

Cross-Reference

I further discuss the GAC in the section "Use or Not Use the Global Assembly Cache (GAC)" later in this chapter.

Obfuscate or Not Obfuscate

If you have developed an application that includes the type of sensitive source code that you would not want your customers (or competitors ) seeing, you may want to look into the topic of obfuscation. The threat of intellectual property theft is real. It is possible to take compiled code through a process called decompilation. At the end of this process, your original source can be reconstructed or reverse engineered. That is, unless you use an obfuscation product.

The job of an obfuscation product is to safely "scramble" the internals of your distributable modules, making them nearly impossible to decompile.

Note	The concern of obfuscation does not apply as much to Web- based (ASP.NET) applications. Although Web-based applications contend with the wit of hackers and virus authors, the threat of decompilation generally applies to instances where the actual compiled modules are distributed to the end user.

Because internal applications are not necessarily exposed to nontrusted parties, you might be more interested in obfuscation in instances where your end user is an external user (working for a different company). If you feel that the rou tines, calculations, and algorithms packaged in your application are not that unique, you might conclude that there is nothing worth stealing. You will have to be the judge of that.

One of the most popular obfuscation products for .NET is Dotfuscator from PreEmptive Solutions. ^[1] It is expected that the Dotfuscator product will be inte grated into a future version of VS .NET. ^[2] In the meantime, you can obtain the Community Edition of Dotfuscator through a free download offer made available by PreEmptive Solutions.

Cross-Reference

I have included the PreEmptive Solutions URL in the "Web Sites" subsection of the "To Learn More" section at the end of this chapter. Feel free to visit the PreEmptive Solutions Web site to read more about their obfuscation product.

The Community Edition of Dotfuscator is advertised as being "fully func tional" and "free for evaluation, personal, or academic use." PreEmptive Solutions also offers a Professional Edition of Dotfuscator. If you were to purchase the Pro fessional Edition, you could take advantage of the advertised feature "one year of support and upgrades."

Naturally, there are other software vendors creating obfuscation products for .NET applications. ^[3] For the time being, PreEmptive Solutions is apparently leading the pack.

Deploy the Release or Debug Version

In your mainframe experience, you have likely come across the occasion to trou bleshoot a production problem. In some of those cases, you may have had the assistance of formatted COBOL memory dumps, interactive debugging, or perhaps File-AID “type information. All of this depended heavily on how you com piled your mainframe COBOL problem. Typically, your program would have been compiled using the most optimal compiler directives.

As you know, what is most optimal for normal production processing is not always most optimal for troubleshooting. The same quandary exists with your .NET applications. When you build your .NET applications, you can choose either the Release option or the Debug option to configure your projects/solution.

When you view an open project in the VS .NET IDE, the Solutions Configura tions drop-down box is visible on the Standard toolbar. You can either make your choice there or navigate deeper to the Configuration Manager dialog box. As shown in Figure 17-2, the Configuration Manager is exposed as a choice on the Standard toolbar. The Configuration Manager window makes available a more flexible configuration for your solutions (see Figure 17-3).

Figure 17-2: The VS .NET Standard toolbar exposing the Solutions Configurations drop-down box

Figure 17-3: The Configuration Manager dialog box

Now comes the fun part. Which choice should you make: Release or Debug?

If you choose Debug, you will create the debug symbols file. This is the .pdb file that is located in your <application>\bin folder. The mapping (MSIL to source code) enabled by this file is invaluable during any reasonable debugging effort. However, if you distribute this .pdb file with your application, you will make it that much easier for a would-be intellectual thief to decompile and reverse engineer your .NET application.

On the other hand, if you choose Release, your production application will be built in its most optimal form. However, in the event that you need to troubleshoot a production problem, you will need to rebuild the solution to reap the benefits of interactive debugging.

Consider the alternative approach of combining the generation of debugging symbols with the Release setting. As shown in Figure 17-4, this is as simple as selecting a check box (that is unchecked by default) on the project property pages.

Figure 17-4: The project property pages Build options showing the check box used to selectively generate debugging information

To make this approach complete, you might even consider using a symbol server to help manage the debugging symbol (.pdb) files that you will be gener ating rather than include them when you deploy your application. Microsoft makes available a public symbol server that you can direct your VS .NET IDE con figuration setting to. Optionally, you can create your own symbol server on your intranet or local server.

Tip	Please refer to your .NET Platform SDK documentation for more information on symbol servers. I have included a Web reference at the end of this chapter to help your research efforts.

Precompile, Batch Compile, or Just-in-Time (JIT) Compile

The discussion of various compilation options is not necessarily a deployment consideration, per se. However, it does help bring to the surface an issue that you might consider addressing in your post-deployment process.

You will recall that I introduced the topic of Microsoft intermediate language (MSIL) in Chapter 8 in the section "Understanding the Common Language Runtime." In that earlier section, you learned that your .NET source code goes through a few "compilation" steps before actually executing. As shown in Figure 17-5, the objective is to create machine code that actually executes.

Figure 17-5: The basic options to generate machine code

As part of your post-deployment process, you might choose to initiate the batch compilation and just-in-time (JIT) compilation in your ASP.NET appli cations (by being the first to "hit" specific pages and methods). Then, your users will experience the lighting-fast execution of the machine code each time. For your non-ASP.NET applications, you have the option of using the Ngen.exe utility to precompile targeted methods to avoid your users initiating the JIT compilation.

Use or Not Use the Global Assembly Cache (GAC)

In the pre-.NET development arena, the most common way to "locate" an assembly (.dll) during runtime was to use the registry. In Chapter 3 in the section "System Registry," I compared the Windows registry with common mainframe practices used to "locate" executables. As part of that earlier discussion, I used the mainframe JCL STEPLIB/JOBLIB and System Master Catalog as analogies .

There was a common thread in that earlier discussion as I contrasted the mainframe and .NET environments. Regardless of the platform, there is a need for multiple applications to be able to locate shared components being targeted for execution.

With .NET, the Global Assembly Cache (GAC) serves this purpose. The GAC provides a location to store managed assemblies destined to be shared across application boundaries. .NET provides a utility, Gacutil.exe, that you can use to manage the GAC (adding or removing assemblies). You can use the .NET Framework Configuration tool Mscorcfg.msc to manage the GAC. Additionally, you can use the Microsoft Windows Installer product to add assemblies to and remove assemblies from the GAC.

Tip

Using the GAC will introduce complexities into your deployment process. Therefore, I offer this rule of thumb: Consider using the GAC only if you have an assembly (.dll) that will be shared by multiple applications on the same physical machine. Otherwise, leave your assemblies in the <application>\bin folder as private assemblies.

The next time you have a project open in your VS .NET IDE, execute the project. Then, while the project is executing, view the Debug tab of the VS .NET IDE Output window. The display in that window will show you exactly which portions of your project are coming from the GAC. To demonstrate this, I will use the sample project MyFirstWinFormVB (from Chapter 13). As shown in Figure 17-6, during an application's execution, the VS .NET IDE Output window indicates the location from which each assembly is loaded and executed.

Figure 17-6: The VS .NET IDE Output window. Notice that the shared assembly System.dll was loaded and executed from the GAC.

In the event that your application's needs justify the use of the GAC, you'll need to create a strong name for your assembly. In the next section, you'll turn to further explore the topic of strong names .

Cross-Reference

Please refer to the "To Learn More" section at the end of this chapter for more information on the GAC and the Gaculil.exe utility.

Use or Not Use a Strong Name for Your Assembly

If you want to use the versioning feature that .NET offers, you will need to generate a strong name for your assembly. A strong name also ensures the uniqueness of your assembly name. A strong name is required in the case of your assembly being used as a shared assembly (in the GAC). The creation of a strong name for your assembly is commonly referred to as "signing your assembly."

Note

A few strong name facts: .NET provides a utility, Sn.exe, to assist you in creating an assembly strong name. You can create a strong name for your private and shared assemblies. If your assembly is intended to be an Enterprise Services (COM+) component, you must create a strong name for your assembly. (This topic is further discussed in Chapter 19.)

Although versioning and name uniqueness may sound like great benefits, you should seek to use these features only if you really need them. In other words, there is a cost incurred in using these benefits. One particular cost is incurred when you sign your assembly: Your deployment process becomes a bit more complex.

To reap the benefits of versioning, your applications will point to specific "versions" of the strong-named assembly. Later, when you need to deploy a new version of the strong-named assembly, you must take extra steps to force existing applications to reference the new version of the strong-named assembly.

There is no doubt that versioning is a great feature enabled by signing an assembly. Just understand what this introduces into your deployment process.

Cross-Reference

Please refer to the "To Learn More" section at the end of this chapter for resources you can look to for more information on strong names and the Sn.exe utility.

Deploy or Not Deploy Multiple Versions of Your Configuration File

I remember using mainframe JCL OVERRIDE statements during my legacy COBOL development and testing. The JCL OVERRIDE statements provided an easy way to use nonproduction resources. For example, I would use a JCL OVERRIDE statement to the test database during my testing phase. The problem came when I would occasionally leave the OVERRIDE statements in and deploy my application to production while still pointing to test resources. This type of deployment concern continues to exist, even with .NET.

The .NET environment offers an XML-based configuration file (or just config file ). I briefly introduced this file in Chapter 15. You can use the config file to store most of your resource directive statements. For example, your database con nection string information will typically be placed in the config file. Both ASP.NET and Windows applications can take advantage of the config file approach by using the Web.config file or the ApplicationName.exe.config ^[4] file, respectively.

Cross-Reference

Chapter 18 presents a full discussion of the XML- based config file.

The settings (e.g., database connection string) placed in your config file during your development and testing are likely to be changed when it's time to prepare for your production deployment. This means that you need to either create multiple versions of the config file or remember to edit the file as appro priate. My guess is that you don't want to end up deploying your application to production while still referring to test-based resources. As I recall, that's frowned upon.

One approach is to create multiple versions of your config file. In other words, create a config file for each environment with self-documenting names (coming from the mainframe, this will look and feel rather familiar). As shown in Figure 17-7, you can then use the Override file feature in the Deployment section of the VS .NET IDE project property pages.

Figure 17-7: Override file feature in the Deployment section of the VS .NET IDE project property pages

Can you believe it? They are even calling them "override files." Just like in the old days. Wow, talk about coming full circle ”this is almost scary. At any rate, you can use this new VS .NET feature to point to the appropriate config file as you prepare for each phase of your deployment process.

Use an Automated or a Manual Approach for Installation

On the mainframe, you may have used tools that served to automate a production deployment. Some of these tools simply copied modules. Others may have inte grated the source management check-in and sign-off processes together with the copying and archiving of modules. You will be pleased to know that the Windows/ .NET platform also offers you the choice of automating your software installation.

Generally, the choice that you make to automate or not to automate will depend mostly on the complexity and needs of your application. In the simplest of cases, you can stick with the manual installation approach. On the other hand, automation will likely be a better choice in the following scenarios:

For most ASP.NET installations
For all .NET Windows application installations where an end user is involved in the deployment process
For all .NET Windows application installations where Internet/browser- based distribution is an option
For all .NET Windows Service installations
For all cases where the GAC is used ^[5]
For all cases where any scripting is needed
For all cases where application resources are used (e.g., Event Log, Message Queuing, or Performance Counter)
For most cases where Enterprise Services (COM+) components are used

Cross-Reference

I further discuss Enterprise Services (COM+) components in Chapter 19.

The preceding list includes most of the common development/deployment scenarios where automating your deployment process will be most attractive. Once you decide to head down the path of automation, you will come to a fork in the road. You will need to decide between the following:

Using the Microsoft Windows Installer software that is already integrated into VS .NET

Purchasing a sophisticated automation software package from the choices available on the market

Note

Microsoft has joined other software vendors in the quest to provide software deployment and management products. Microsoft offers a product called Application Center that helps fill the need. In addition, the company Wise Solutions has created a product called Wise for Visual Studio .NET that integrates nicely into VS .NET. These products and others are often considered during any serious software evaluation line-ups.

As with any software purchase, you and your organization will need to conduct a proper product evaluation. In the meantime, I suggest you take advantage of the tools already included in your VS .NET toolset. You may discover that you already have enough software to meet your immediate needs.

Cross-Reference

Microsoft has published a free downloadable guide titled "Team Development with Visual Studio .NET and Visual Source- Safe." You should refer to this document as a starting point for procedural guidance. It will especially be useful if you have a development team using VS .NET and Visual SourceSafe (VSS). I provide the URL for this document in the "Web Sites" subsection of the "To Learn More" section at the end of this chapter.

Let's now explore how you can use the Microsoft Windows Installer software tool to help automate your .NET software deployment. In the section "The Manual Approach: XCOPY or Copy" later in this chapter, you'll explore the alternative to deployment automation: doing it the manual way, without Windows Installer.

^[1] PreEmptive Solutions announced the availability of the Dotfuscator product for Microsoft .NET applications at the VSLive! event in San Francisco on February 13, 2002.

^[2] According to a recent GotDotNet "featured site" article ( http://www.gotdotnet.com/featured_site/preemptive/default.aspx ), PreEmptive Solutions is a member of Microsoft's Visual Studio Integrator Program (VSIP).

^[3] These same vendors are creating obfuscation products for other platforms as well (e.g., Java).

^[4] Microsoft's documentation mentions a naming convention of ApplicationName.exe.config for the Windows application configuration file. The config file that matches that naming convention is automatically created for you. You actually create the App.config file. When you "build" your solution/project, the App.config file is copied to the \bin folder with the name of ApplicationName.exe.config . You then continue to edit the App.config that remains in the application folder. This automatic copying scenario repeats with subsequent builds.

^[5] This would include (but is not limited to) all cases where you need to redistribute Fujitsu's NetCOBOL for .NET runtime. In other words, if you develop your applications using COBOL .NET, an automated deployment is suggested.