Reap the benefits of using VB ActiveX .dll files in Active Server Pages

Transferring business logic to Visual Basic ActiveX .dll files can increase the performance of your Active Server Pages. Find out how to implement this technique and see how much more efficiently your pages will load.

Coauthored by Drew Wutka

Nobody likes to work harder than necessary, and you're probably no exception. So if we told you that a simple technique could make your ASP pages faster and more efficient, you'd probably be interested in learning more. The trick is to transfer much of your business logic from your ASP page to a Visual Basic ActiveX .dll to improve overall page performance.

Why you should use an ActiveX .dll
A .dll file created in Visual Basic is actually an ActiveX object. These objects are built on Microsoft's Component Object Model (COM) technology. You'll use them to create classes (or code objects) that can be used by any other program that references the .dll.

Developers turn to .dlls for a number of reasons, and each project won't include every advantage. However, once you try this approach, you may find yourself using the ActiveX .dll technique more than any other. Let's look at the many advantages of using an ActiveX .dll.

Better performance
Without a doubt, one of a developer's main concerns is decent performance. An ActiveX .dll is much faster than a plain ASP page. Let's consider a simple example. An ASP page that counts a variable from 0 to 10 million and then displays the string "Done" completes its task in 26,087 milliseconds. The comparable VB .dll file required 100 milliseconds to complete the task. The VB .dll was 260 times faster than the ASP page.

In such a test, the speed difference is extremely noticeable, since the ASP version took 26 seconds to run, but the .dll version took less than a second. Just keep in mind that the speed difference is going to be relative to the amount of work the code has to do. That is, the more work the code performs, the bigger the speed difference. The second running of both test files shows an even greater differential. The ASP page took 25,156 milliseconds; the .dll took 70 milliseconds—the .dll was 359 times faster.

You might be wondering why both files executed faster the second time around. During the first run, the ASP pages were raw, meaning everything had to be loaded from scratch. The second run was able to use cached pages. The same is true for the .dll example. Both files ran cached pages during the second run.

The .dll is much faster than the ASP page for two reasons:
  • The .dll is compiled. That means the file is run in machine language, which is as fast as it gets. The ASP page runs script that's processed through a scripting engine. Consequently, each step must be interpreted and then processed.
  • The .dll uses a variable that's declared as a Long data type, which requires no interpretation by a 32-bit processor. The scripted page uses a Variant (required in ASP). The Variant variable must be converted to a number and then back again for each count, which significantly adds to the processing time.

Variable declaration is better
Not only is it faster to run declared variables—they're easier to program because variable type conversions aren't required. Variables can be declared as a particular variable type initially, avoiding additional references and lines of conversion code.

Source code is hidden
A .dll file keeps your source code hidden and safe from hackers (for the most part). An ASP page stores script as plain text on your Web server. The pages are easy to access once someone gains access to your Web site's files, so your source code is exposed and vulnerable. Using custom ActiveX .dll files to handle your site's business logic severely hampers a hacker's access to your code. Only the compiled .dll is available, not the source code.

Richer development environment
You'll probably use Microsoft Script Editor to produce ASP scripts. Although it's an adequate tool, it offers only basic scripting features. By contrast, Visual Basic is a rich development environment. In short, there really is no comparison—one is a scripting tool, one is a full-blown development package.

More efficient cross-development
VB created .dlls can easily be acclimated into other environments, such as Microsoft Access and Visual Basic executables. On the other hand, a developer must re-create an ASP page's task when moving the functionality to another environment.

More efficient ASP pages
An ASP page that contains all your business logic can become extremely code-heavy and cluttered. The .dll is a more efficient solution because it contains all the logic and the ASP page simply interacts with it. This arrangement results in much cleaner and more efficient code.

A few disadvantages
For the most part, the advantages of using an ActiveX .dll far outweigh any disadvantages, but there are a few problems you'll want to keep in mind. First, an ActiveX .dll can increase your development time in some instances. For example, developing the.dll file in our variable-counting example took about two minutes; the ASP page required only one minute. However, it isn't as bad as it may seem at first. Eventually, a library of well-organized and reusable ActiveX .dll classes can decrease your development time further into your project.

Second, the typical ASP page is simple to modify: You just add script and save the file. Updating a .dll that interacts with an ASP page is more complex because you can't compile the .dll into place without restarting the Web server service. However, as a general rule, you can simply restart the Web server service and then recompile or copy the new .dll into place while the service is running again. Restarting the service should take no more than a second, so there should be virtually no interruptions. Since Web applications are a hit-and-go process, your end users will notice only a brief interruption—and only if they try to load a page the exact second you restart the service.

Third, runtimes must be installed on the Web server. If you use an ActiveX .dll within an ASP page but you haven't installed the VB runtimes from some other source, simply use the Package And Deployment wizard to make an installation process for your .dll. Install this setup program on your Web server, and you're off and running. Remember, you may need to install other references—such as MDAC if you are using ADO—if your .dll uses them.

Some tips and tricks for working with ActiveX .dll files
Working with .dlls isn't difficult, but a few simple tips should make your experience smoother. Don't forget that you must register a .dll to use it. To register an ActiveX .dll, use the Windows API call:
Public Declare Function .DLLSelfRegister Lib "vb6stkit.dll" (By Val lp.dllName As String) As Integer

After modifying a .dll, you may need to reregister it if you added a new class or you copy the source to another development computer (something you should try to avoid). Compiling an ActiveX .dll assigns a unique identifier to the file. If you copy the source to another machine and then compile it there, the identifier changes to reflect the current computer. Consequently, each time you copy the .dll to the Web server, you will have to reregister it, regardless of the type of development changes you made to the source.

Working with .dll files does require that you manually restart the server occasionally. The easiest way to manually restart Internet Information Server (IIS) is to connect via Computer Management (a Windows 2000 utility). The Web server service is called World Wide Web Publishing Service. If you have the Windows 2000 Server Resource Kit, you can use the service.vbs tool and run the batch file:
cscript service.vbs /X /N W3SVC /S IISmachinename
cscript service.vbs /G /N W3SVC /S IISmachinename

When debugging the .dll, use Visual Basic's Debug feature, which allows you to walk through your code when you load an ASP page. You can learn more about debugging Visual Basic .dll files within Visual Basic from the Microsoft Knowledge Base.

Win-win with .dlls
There's really no comparing a plain ASP page and a page that interacts with a Visual Basic ActiveX .dll. The latter is faster and far more efficient. That makes your users happy, which in turn, should make you happy. You produce a superior product for your users and often produce a reusable .dll. Everyone wins with this arrangement.

Susan Sales Harkins is an independent consultant and the author of several articles and books on database and Web technologies. Her most recent books are SQL: Access to SQL Server (Apress), Mastering Dreamweaver MX Databases (Sybex), and Absolute Beginner's Guide to Microsoft Access 2002 (Que). Drew Wutka is a Microsoft Access/Visual Basic/Web developer for Marlow Industries, Inc.

About Susan Harkins

Susan Sales Harkins is an IT consultant, specializing in desktop solutions. Previously, she was editor in chief for The Cobb Group, the world's largest publisher of technical journals.

Editor's Picks

Free Newsletters, In your Inbox