The Manual Approach: XCOPY or Copy

Generally speaking, you should use the manual approach only for nonproduction deployments. In other words, if you want to move your files from one development machine over to another development or testing machine, the manual approach is appropriate.

However, as soon as you start preparing for production (and even when you are preparing for staging) you will want to begin to create your Windows Installer ^{[8 ]} setup projects. After all, even your setup projects need to be tested .

Tip  

The more complex your application, the more certain that the manual approach is not appropriate. Use of the GAC or IIS can also be used as deciding factors. See the section "Automated or Manual Installation" earlier in this chapter for other factors to weigh when you want to choose between a manual and an automated deployment.

As part of your retraining effort, you should know how to manually install your .NET application. In this section, I cover two choices for manual deployment:

• The XCOPY approach

• The Copy Project approach

XCOPY-Based Deployment

In several .NET conferences that I had the pleasure of attending , I observed that most attendees generally got excited when the topic of XCOPY-based deployment was mentioned. I find it highly ironic, now that the dust has started to settle , that XCOPY-based deployment is discouraged and frowned upon. Oh, well.

Even stranger, each time I saw XCOPY-based deployment demonstrated, the presenter was either dragging and dropping or copying and pasting files and folders. Why is that strange ? There is an XCOPY DOS-era command available (see Figure 17-31). However, not even once did I see the conference presenters open the Command window to actually execute the XCOPY DOS command. I suppose "XCOPY" sounds cooler than "dragging and dropping" or "copying and pasting." Oh, well.

Figure 17-31: At a command prompt, you can enter XCOPY /? to see a listing of all of the options/switches available for use with the XCOPY DOS command.

Note  

You can use the XCOPY DOS command to "copy" files and folders.

Suffice it to say, if you can drag and drop or copy and paste your application files, you can proudly say that you are using the XCOPY-based deployment approach. Just keep in mind that there is an XCOPY DOS command that you can use as well. The bottom line is, there is value in both types of "deployment" approaches. The following points speak to this value:

• The drag and drop or copy and paste approach: Compared to the "registering DLLs" type of deployment normally associated with Wintel legacy COM objects, the drag and drop or copy and paste approach can be considered a productivity feature. Consider limiting this approach to the deployment of "small" applications.

• Using the XCOPY command: The power of the XCOPY command is best seen when you are attempting to deploy a Web project that has a large number of screens (.aspx files). You can use command-line switches with the XCOPY command to easily filter out any specific files that you may not need to deploy (.resx or .vb files). Additionally, you can execute the XCOPY command from within a DOS batch file (.bat). ^[9]

In the next section you will take a look at one other way to manually deploy your .NET application.

The Copy Project Feature

A VS .NET special Copy Project feature is available ^[10] when you are working with ASP.NET applications. With your application project selected, you can access this feature from the Standard toolbar by selecting Project Copy Project (see Figure 17-32).

Figure 17-32: Accessing the VS .NET Copy Project feature

Note  

At this time, it appears that the VS .NET Copy Project feature is not available for COBOL .NET projects. Consider trying the VS .NET Copy Project feature using VB .NET.

Once you launch the VS .NET Copy Project feature, you need to perform the following tasks :

1. Select the destination project folder. This will equate to the IIS virtual directory.

2. Select the Web access method. For demonstration purposes, I chose FrontPage, which is the default.

3. Select the scope of your "copy." For demonstration purposes, I chose to copy the minimum files needed. This is the default setting.

As shown in Figure 17-33, the default settings are typically suitable.

Figure 17-33: The Copy Project window with default settings

If you are using the Copy Project deployment approach or the XCOPY deployment approach, you will be sacrificing several benefits. For example, when it comes to your ASP.NET application, you will need to perform your basic IIS con figuration manually. The following section gives you a few pointers for a basic IIS configuration task.

Note  

During my testing, the VS .NET Copy Project feature successfully created an IIS virtual directory. Not bad! Nevertheless, it is likely that you will want to further configure the virtual directory that the Copy Project feature creates for you.

A Basic IIS Configuration Task

When you manually deploy an ASP.NET application, at a minimum, you will need to create an IIS virtual directory. The steps you need to perform to accomplish this task are as follows :

1. From the Windows Control Panel, select Administrative Tools. Optionally, click the Start button and select Programs Administrative Tools Internet Information Services.

2. Launch the IIS MMC snap-in.

3. In the left pane of the IIS MMC snap-in, open the tree view to expose the Default Web Site node.

4. Launch the Virtual Directory Creation Wizard by right-clicking the Default Web Site node and selecting New Virtual Directory, as shown in Figure 17-34. Note that the look and feel of the IIS MMC snap-in varies slightly depending on the version of the Windows operating system that you are using. The display shown in Figure 17-34 is typical of Windows XP Professional.

   
   Figure 17-34: Launching the Virtual Directory Creation Wizard

5. Follow the prompts to complete the virtual directory creation. Click Next.

6. Enter the desired name of the new virtual directory at the Virtual Directory Alias prompt. In Figure 17-35 I entered MyTestVirtualDirectory for demonstration purposes. Click Next.

   
   Figure 17-35: Enter the desired name for your virtual directory at the Virtual Directory Alias prompt.

7. At the Web Site Content Directory prompt, enter the physical location where your files will be stored. For demonstration purposes, I entered C:\Inetpub\ wwwroot \WebApplicationSampleCobol (see Figure 17-36). You can use the Browse button to help locate the correct folder location. Click Next.

   
   Figure 17-36: Enter the physical location where your files will be stored at the Web Site Content Directory prompt.

8. At the Access Permissions prompt, leave the defaults as set. As shown in Figure 17-37, the defaults should be sufficient for this demonstration. Click Next and then click Finish.

   
   Figure 17-37: The Access Permissions prompt

9. As shown in Figure 17-38, your new IIS virtual directory has been created for you. You can further customize the virtual directory through the specific virtual directory's properties window (to access this window, right-click the specific virtual directory).

   
   Figure 17-38: The new MyTestVirtualDirectory virtual directory

10. Test the virtual directory. In your Web browser, enter the following in the address bar to browse a specific document in the virtual directory: http://localhost/MyTestVirtualDirectory/webform1.aspx .

That's it. That's all you need to do to create a basic IIS virtual directory. Keep in mind, however, there's much more for you to learn before you can consider yourself an IIS administrator. As your retraining needs dictate , consider visiting the Web sites listed in the "Web Sites" subsection of the "To Learn More" section at the end of this chapter.

How Are You Going to Distribute Your Package?

You may end up needing to copy files to some type of storage device, download files using FTP, publish from within Visual SourceSafe (VSS), or use a shared network folder to drag and drop or copy and paste to. For a .NET Windows application, you may even decide to look into the new Zero Install and Zero Administration Windows (ZAW) approach.

The Zero Install and Zero Administration Windows (ZAW) approach involves a two-step distribution process. In the first step, you distribute your Windows application package to your Web server. The second step is initiated by your end users navigating to your Web site with their browser, clicking a hyperlink, and downloading the Windows application to their desktop.

 

^{[8 ]} Optionally, you might consider using a competing third-party product.

^[9] DOS batch files on Windows are very similar to the mainframe CLIST and REXX scripts that you may have created.

^[10] According to Microsoft's documentation, "FrontPage Server Extensions must be installed on the target server to use the Copy Project command."