Many developers are starting to use Microsoft Visual InterDev 6.0 to build applications, but a good bit of confusion surrounds using it, which has to do with configuring the Visual InterDev server. If you don't configure the server correctly, the developer and possibly application users will experience a variety of problems.
In "Setting Up and Configuring IIS," August 1998, I explain how to install and configure Microsoft Internet Information Server (IIS). When I wrote the article, Visual InterDev 6.0 was a beta and many features were unstable. Because Visual InterDev 6.0 has been available since mid-1998, I want to revisit installing and configuring IIS and Visual InterDev 6.0.
Developers frequently ask me two questions with regard to using and configuring IIS and Visual InterDev 6.0. What OS do I need for my server? Can I use Windows 9x, or must I use Windows NT? The answer is simple: Use NT Server or NT Workstation to get the most out of Visual InterDev because NT supports all the Visual InterDev server features. With Win9x as the server, most features will work fine, but you won't be able to use the Visual InterDev Active Server Pages (ASP) debugging features and you won't have access to the IIS Web server management features. Because NT provides the most functionality for Visual InterDev 6.0 developers, this article highlights configuring and using Visual InterDev 6.0 on NT.
In addition to choosing NT as the OS, you must also use the appropriate Web server to host Visual InterDev applications. Don't use the Web server that comes with FrontPage because this server won't work with Visual InterDev applications. With NT Server 4.0, you need to use IIS for the Web server. With either NT Workstation 4.0 or Win9x, you need to use the Personal Web Server (PWS) for the respective OS. The NT 4.0 Option Pack, which the Visual InterDev 6.0 CD-ROM set includes, provides the proper Web server for each OS.
Before you start the installation, find the README file (readmevi.htm) in the root directory of the first CD-ROM, open it, and read it. This file documents many problems and gotchas that you might discover when configuring the Web server and its components. Although you might be tempted to hit the keys and go, this README file is worth finding, reading, and saving.
Server Software Installation
A production or development server requires certain software to operate correctly. At the start, you need IIS 4.0 (or PWS 4.0 for NT Workstation) or later, Microsoft Data Access Components (MDAC), and Visual InterDev Server 6.0.
Servers that developers will access using Visual InterDev will also require FrontPage Server Extensions. All communication between the Web server and Visual InterDev occurs over HTTP using FrontPage Server Extensions. You might need to install the extensions on your production server if you use a tool that requires the extensions to copy files to and from the server or your developers use robots or other runtime features that require the extensions. If you can eliminate the need for FrontPage Server Extensions, you can also eliminate some security concerns. But developers and Web masters have limited access to servers without the extensions.
To begin software installation, choose the Visual InterDev Server setup option to install the proper versions of the scripting engines and the Data Environment runtime files. When you install the NT Workstation PWS, select the option to use the Microsoft Management Console (MMC) tools. PWS installs the MMC and the IIS snap-in that provides the maximum management capabilities. Using the PWS interface alone will limit you to the Win9x management options.
Visual InterDev 6.0 also requires server components to operate correctly. The server components are either upgrades to existing components such as FrontPage Server Extensions or new components such as Remote Machine Debugging. The IIS or PWS installation will include FrontPage Server Extensions, the Visual InterDev remote rapid application development (RAD) Deployment Support component, and the Remote Machine Debugging component. You might also want to install the Visual Studio Posting Acceptor component to build applications that let users upload files to the server. You need to select these extension and component options during the Option Pack installation steps. Follow these steps to install the server components:
- Insert the first Visual InterDev or Visual Studio (VS) CD-ROM. Setup.exe automatically runs the Installation Wizard, which will lead you through the installation process.
- Select Server Applications and Tools, then click Next. (If you've installed IIS, you can select Server Applications and Tools—Add Only—to add any further options.)
- Select Launch BackOffice Installation Wizard, then click Install. The BackOffice Installation Wizard will prompt you to select the installation method.
- Select Custom, and click Next.
- Verify that your disk contains enough space, then click Next.
- Screen 1 shows the available BackOffice programs and components. At a minimum, select the Remote Machine Debugging and Visual InterDev Server options.
- Complete the steps in the wizard.
After you've installed or added components for the server installation, you can apply service packs. You need NT 4.0 Service Pack 4 (SP4) or later, VS SP1 or later, and Microsoft SQL Server 6.5 SP4 or later to fix known configuration problems that can affect your Visual InterDev applications.
NT 4.0 SP4 fixes problems with NT, adds new features, and replaces the IIS asp.dll file to enable ASP debugging with Visual InterDev 6.0. Microsoft hadn't released SP4 before it shipped Visual InterDev 6.0 and VS. To fix a problem in the asp.dll file that affects the debugging of ASP applications, Microsoft included a hotfix in the VS and Visual InterDev CD-ROMs that updates the file. If you install NT 4.0 SP4, you don't need to apply the hotfix. If you've already applied the hotfix, you still need to install SP4 because the hotfix doesn't fix other NT or IIS problems.
If you're using SQL Server with your applications, you need to install the latest SQL Server service packs. The latest service packs will ensure that you have the most recent patches and driver updates.
Also, you need to check the list of known bugs and problems for Visual InterDev 6.0. You can find information about bugs and fixes at http://msdn.microsoft.com/ vinterdev/technical/support.asp. You need to be aware of the list because some of the problems can affect setup (e.g., see "BUG: 'Unspecified Error' When Using SQLOLEDB Provider," http://support.microsoft.com/ support/kb/articles/q194/0/00.asp).
Before beginning configuration, you need all the server software installed. If Visual InterDev 6.0 is on the same system as your Web server, everything will work fine after you install the software. You will be able to create and delete applications, add content to them, and use them.
At this point, you can try the debug features of Visual InterDev 6.0. Remember that the debug features work only when you're using NT Server or NT Workstation to host the Web application. Before you extensively use the debug features, visit the Microsoft Web site and download the debugging white paper and utilities. "Microsoft Visual InterDev 6.0 Debugging" (http://msdn.microsoft.com/ vinterdev/headlines/videbug.asp) details how to set up both servers and workstations to let developers debug applications. From this URL, you can also download the debugging utilities and an analysis program (viddbg.exe) to test and report on the configuration of a server or workstation.
Server Component Configuration
Web development offers many discussion topics and whether the Web site is the Internet, an intranet, or an extranet, many of the problems are the same. Many developers and system managers worldwide pose the same question: How do you use Visual InterDev 6.0 in a team environment? Because this article is about configuring the Web server to work with Visual InterDev, let's tackle the problem of using Visual InterDev 6.0 in a team environment.
Figure 1 shows a a typical implementation of NT servers running IIS and Visual InterDev 6.0 workstations. This diagram illustrates several principles. First, the production server is a separate server from the development server. Developers can access the development server for creating and managing content, yet only Web masters or the management team can access the production server. Because Web masters control access to the production server, they don't need to worry about developers creating or changing new content on the production server without their knowledge. Developers can work on the development server to create new content and test applications without worrying about causing problems on the production server. Web masters can access the development server and copy the finished application to the production server.
Now let's examine the developer workstation. Developers can each run PWS on their workstation to create a local development server. Developers can share files from their local development server with other developers who are working on the same project. When a developer is ready to move a file to the development server, the developer can copy a file or an entire site to the development server. Visual InterDev's ability to host multiple projects at once, with projects pointing to different Web sites and servers, makes using multiple local development servers possible.
Local development servers are also important for developers using the new debugging features. I recommend configuring developers' workstations to debug applications locally for two reasons. First, debugging an application puts the application into an isolated mode that makes the application and the server run slowly. Second, only one user at a time can remotely debug an application on a server. Therefore, 10 developers will need to take turns debugging applications on the development server. Local debugging lets developers debug at any time without affecting the production or development server.
When you provide local debugging, you don't want to entirely prevent developers from using remote servers to debug. You will want to reserve remote debugging for times when developers can solve a problem by using only the remote debugging features. Therefore, I recommend reading the debugging white paper thoroughly and configuring your servers to provide remote debugging. The Distributed Component Object Model (DCOM) configuration section of the white paper applies to systems that use remote debugging. For the systems to work correctly, you need to apply NT 4.0 SP4 or the hotfix to developer systems that function as local debugging servers. When you've finished configuring the servers, test the configuration from several developer systems.
Final Note
I strongly suggest that you install Visual SourceSafe on your network and require all developers to use it during development. Implementing source code control is simple and painless using VS 6.0, which includes Visual SourceSafe. Visual SourceSafe is easy to configure, and you can literally save the day when a developer needs to trace changes or revert to a previous version of a file.
