Page #88 (Chapter 13 - Deploying WebClass Applications)

	Chapter 13 - Deploying WebClass Applications
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	Preparing for Deployment

	Deploying a Web application isn't much different from deploying a standard Windows application. There are only three critical differences:

	•		Compiled WebClass applications run under different permissions from those in the Visual Basic integrated development environment (IDE).

	•		Compiled WebClasses run on multiple threads. In the IDE, each WebClass runs on one and one thread only. Resource contention that you won't see during development can become an issue after deployment.

	•		The target server will not be your development server, won't have the same directory permissions that your server does, may not be the same service pack version, and will have different security settings. If you're lucky, you'll have Administrator access to the target server. In both cases, you can help either yourself or the server administrators by following the guidelines in this chapter.

	You need a minimum of two servers to test an installation: your development server and a test server. The test server cannot be the development server because all paths, files, DSNs, graphics, virtual directories, permissions, DLLs, and other resources and settings presumably already exist and work on the development server. The point of testing the installation is that the target environment is usually unknown and often uncontrollable. In other words, you may be delivering your application to a server that is radically different from your development server.

	Clean Up the Code

	Now's a good time to go through the code and eliminate unneeded methods and variables. It's too early to remove any debugging code, although you should be able to turn the debug output on and off easily for testing. To clean up the code, take the following steps:

	1.		Check the project references list and remove any unnecessary references. The Visual Studio Package and Deployment Wizard (PDW) includes external DLLs based on the project references list.

	2.		Delete unused files. Don't forget to delete unused HTML template files—you'll need a clean list to create your installation.

	3.		Back up the project. As a developer, you're sure (or you should be) that the application runs perfectly right now. You should save that known state in case you make changes during the deployment process and want to undo them later.

	4.		Make sure that all file references within the project use relative URLs. Never include the server name or IP address in any code. The server name will always change. If your root directory name clashes with an existing name, or if, for whatever reason, the clients want to change the root to another name, your program will still work. You can obtain the server name and program root at runtime with the Server.MapPath method.

	5.		Search your program for references to external resources such as log filenames, database DSNs, etc. As you find them, move them to the global .asa file and store them as Application-level variables. Change the code so it references the Application variables. That way, you can easily change DSN names, sign-ons, passwords, and external file references, regardless of the resources' locations or names. If security is an issue, put the references in an external file and encrypt the file. The point here is that those filenames, paths, machine resources, and database resources can and will change names and locations. In many cases, these changes are outside your control and will break your application. You want to get the references from a location that you can change easily, preferably without recompiling and reinstalling your application.

	6.		Try to rename files specific to the application in a consistent manner. That makes it much easier to find and remember files later. It also decreases the risk that a file you're installing will conflict with the name of a file already on the system.

	7.		Make a version number for your program and provide a method to retrieve it. For example, the About box found on the Help menu in most Windows programs provides that information. Although your browser-based application may not have an About box, you can provide a way to display the version number.

	Test in Compiled Mode

	Before you can consider your application ready to deploy on another computer, you need to test it in compiled mode. Compile the project and all the DLLs. Close VB and test the application. Better yet, have someone else test the application. Unless your application runs successfully outside of the VB IDE on your development server, it will never run on someone else's server.

	Testing in compiled mode is always important, but it's especially important for WebClass applications. When you run a WebClass in the IDE, it always runs on a single thread and it always runs as "you." In compiled mode, it runs as the IUSR_MachineName or IWAM_MachineName account. In other words, the permissions available to the WebClass in the IDE are different from those out of the IDE.

	Generate Likely Errors

	Generate errors for the problems most likely to happen. By likely errors, I mean outside resources and references that your application depends on that tend to change over time. For example, if your application opens connections to a database, shut down the database, then see how your application traps the error. Where do the errors appear? On the browser screen? In the Event Application log? In the Event Security log? You need to know so that you can debug the application remotely on an unfamiliar server.

	If your application needs write access to a directory, shut off that access. Delete log files and change DCOM permissions. All these things are out of your control after the application leaves the development stage, but they all happen. Neither you nor anyone else on the development team will remember the information after a few weeks, so write down the exact error messages and the solutions.

	If you follow this advice, you'll probably want to go through at least one more testing and revision cycle to beef up the error reporting. I can assure you that this is time well spent if you're deploying to a remote server—one you can't physically reach or on which you don't have Administrator permissions. Review Chapter 6, "WebClass Debugging and Error Handling," for more information about trapping and reporting errors.

	I often write "hidden" features into a program that can aid in debugging delivered applications. It's best to isolate these features as far as possible from other program requirements. ASP programs are excellent candidates for these features because they're small and they work as long as the server is working. Some examples are an ASP file that tests database connections, one that lists the contents of the global.asa file, one that checks resources, and one that lets you run SQL code against a database such as iSQL. If you have FTP or FrontPage access to the target server, you can even write and deploy such applets after a problem occurs.

	Put the error messages and solutions in an .htm file that accompanies your application and keep a copy for yourself. When you get a support call, you'll be able to tell the caller where to look and what to do to solve the problem.

	Deploy to a Test Server

	If possible, install and test the application on a local server—one where you can physically access the machine, start, stop, and even reboot it. Although event logs can be helpful, other server administrators may not want to help you debug your application. Do not install VB on the server unless you can also install VB on all the target servers.

	All developers can run programs on their computers; running a compiled, multiuser application on someone else's computer is a different problem. Debugging a compiled application requires its own set of skills. Practice on your server, not your client's server; but practice on a test server, not the development server.

	Beta Test the Application

	Many applications run perfectly when tested by the author, but fail miserably when tested by "real" users. By real users, I mean members of the target audience. Real users don't know what input the application expects, so they do unexpected things.

	As early as possible, and on an ongoing basis during development, you should try to get several members of your target audience to use or at least critique the application. A decent sample is five to ten people. You'll find that you can catch most bugs, misconceptions, and missing features if you let just a few people use the application.

	A real beta test, though, occurs as a next-to-final step. You install the application on a server and let several people use it. They should treat the application as though it were the production version. Fix any problems that arise.

	When the application has passed muster in beta form, you can remove the debugging code—it's ready for production. Be sure to recompile and test again without the debugging code.

	Determine the Target Server's Configuration

	When you're delivering to a known target server, you may be able to call ahead to find out the configuration of that server. The earlier you can do this in the development process, the better. For example, developing with the latest and greatest version of ADO will do you no good if the target server is still running version 1.5. Similarly, taking advantage of the many convenient features of SQL Server version 7, such as 8,000-character varChar fields, won't work if the target database server is running version 6.5. Server administrators are notoriously "difficult" when you tell them they must upgrade their equipment or software to accommodate your application.

	If you're developing commercial applications, you will need to create more than one version of the application, design for the lowest common denominator, or be willing to give up possible sales to use the latest technology.

	In all cases, you'll want to design the application to isolate version-dependent issues so that you can change component versions and databases easily to meet the technical requirements of the customers. For example, if all your database accesses happen via stored procedures, your application will work on any database where you can re-create the set of stored procedures. Moving the application from SQL Server to Oracle may be as simple as creating the stored procedures and copying the data.

	I've sometimes found it useful to begin applications by having the program itself check resource availability and versions. Although that may slow down application initialization, it's better than end-user error messages. Alternately, you can write such checks so that they are performed on demand—perhaps via Administrator options or via an unpublished "back-door" URL that runs a method in your WebClass. Using these techniques, you can at least help determine problems after deployment.

	When all else fails, you'll want to keep people from accessing your application while you work on it. Create an ASP file with an appropriate message, for example, This application is temporarily out of service for maintenance…. You can rename the ASP file that launches your application and substitute the out-of-service message file to temporarily disable the application. When you've solved the problem, restore the original filenames to let people access the application again.