Contact Desaware and order today! 

Sign up for Desaware's Newsletter for the latest news and tech tips.

VersionStamper and DLL Hell - What's really going on here?

Copyright © 2001 by Desaware Inc. -- All rights reserved.

Introduction

In our advertising for VersionStamper, we claim that it can help you eliminate component conflict problems. The reactions to our claims vary, taking some of these forms:

• We don't believe you!
• Why do I need this when I already have an installation program?
• Won't Microsoft's Active Install solve this problem?
• Wow - it really does work (this from customers)

What I hope to do in this brief article is describe our philosophy in creating VersionStamper, and how you can deploy it to solve a surprisingly wide variety of problems.

There are three critical ideas that are important to understand about VersionStamper.

1. Most Windows applications use components. And they won't run if any of them are missing, obsolete, mis-registered, or corrupt.
2. VersionStamper is a programmer's toolkit. It is not an application (though it contains several). It is intended for use by IS and development team software developers.
3. VersionStamper can be used on any application, both those you develop, and those developed by others. This opens the door to a wide variety of applications by IS departments.

Let's consider these one at a time.

Applications and Components

Most Windows applications use components. And they won't run if any of them are missing, obsolete, mis-registered, or corrupt.

This statement is probably well understood by anyone reading this article. If you think about it, there are two parts to the problem.

• First, you need to determine the component dependencies for your application.
• Second, you need a way to determine accurately which components are actually loaded on a client's system, and compare them to the list of dependencies.

Most modern installation programs include tools to determine dependencies for your applications. Some do a better job of it than others. VersionStamper uses three types of dependency checking:

• It can scan the DLL file.
• It can scan a Visual Basic project (including source code).
• It can examine actual component use while the application is running.

All of these techniques can be combined using the VersionStamper dependency wizard to obtain an accurate dependency list for any application.

Let me stress that - ANY application. Not just applications you create. Hold that thought.

Client side scanning

Determining which components an application will actually see when it runs is the second part of the verification process. To do this you must run code on the client - specifically, code that uses the VersionStamper scanning control or component.

VersionStamper can be deployed in two ways to perform this scanning.

• It can be incorporated into your own applications to make them self-verifying.
• It can be deployed in a standalone program that you create that is configured to do a dependency test for a particular application or group of applications. (We call these "Emergency Rescue Programs").

The dependency list used for determining conflicts can be almost anywhere. You can embed it into your application. You can download it dynamically from the web or an FTP site, or you can even use an ordinary text file.

What makes VersionStamper unique again is its ability to correctly perform dependency scans for any application - even those you do not create. Normal installation programs often provide some degree of dependency checking and even repair capabilities, but only VersionStamper is able to generically determine dependencies and perform conflict resolution for an arbitrary application or group of applications.

Conflict Response

The VersionStamper scanning components are small, high performance ATL based components that can find conflicts that exist. But what you do with that information is up to you.

We provide a wide selection of high level response code in the form of Visual Basic classes that include full source code. Responses can range from informing the user via a message box, to Emailing a report to a help desk, to performing an automatic upload of newer components. The response choice is entirely up to you and is 100% customizable. You can drop in one of our canned solutions for a quick deployment, modify them slightly to suit your needs, or create your own response from scratch.

VersionStamper Strategies

VersionStamper is NOT an application. It is a programmers toolkit that is designed to help software developers and IS departments create solutions to the problems of distributing component based software. It contains extensive sample source code and technical documentation on distribution strategies. Some of the solutions we've heard about include these:

For Application Developers

• Add auto-updating capabilities to applications
• Dependency checking during "Splash-Screen" initialization.
• Prevent running the application if dependencies are missing.

For Enterprise Developers

• Check and download most recent business objects for 3-tier thick client applications.
• Rapid deploy updates across multiple client systems.
• Create remote diagnostics for client systems.

For IS Departments

• Detect changes to client systems (maintain a database of components on each system).
• Determine component changes to a system caused by installation of an application.
• Create dependency lists for standard installed groups of applications.
• Instant determination of client configuration using remote diagnostics.
• Create standalone verification tool (for systems that are truly scrambled).
• Add dependency checking as part of (late night) scheduled maintenance on client systems and servers.

Why is VersionStamper Unique?

To understand what makes VersionStamper unique, it is necessary to consider how it differs in philosophy from other approaches:

Installation programs

VersionStamper is not an installation program, though it can be used in that way for some applications. It lacks the advanced user interface and scripting that installation programs feature. VersionStamper's strength lies in what happens after the installation is complete. Installation programs fall flat when it comes to dealing with changes to a system made after installation - in most cases you are stuck with simply reinstalling the application and hoping the problem will be solved. VersionStamper is the ideal complement for installation programs when you distribute your applications.

VersionStamper is also unique in its ability to work across applications, and work with other people's applications. Installation programs are designed primarily for use when deploying your own application.

Active Install

Microsoft's new Active install will gradually be deployed with more and more applications. Nevertheless, it does not provide a magical solution to the DLL-Hell problem.

• It requires that the developer use it (and Active Install is not particularly easy to use). Programs that don't use Active Install gain no protection from the technology.
• It requires that Active Install be itself working and configured correctly on the client system. Any failure in the subsystem or corruption of the installation database will cause problems.
• Active Install must be installed on the client system to work. It is useless on older systems and 16 bit software.

VersionStamper works with any application, and comes in 16 bit editions as well. VersionStamper works on all current Microsoft operating systems (and a few obsolete ones such as Windows 3.1).

System Management Tools

VersionStamper provides a powerful independent complement for high end system management tools. It allows you to deploy small scanning applications to catch problems that the tools might miss. Even beginning Visual Basic programmers can quickly create applications that perform independent diagnostics that are not dependent on the correct functioning of the system management tools.

Conclusion

It's easy to understand why VersionStamper is a bit hard to believe - the problem of component conflicts has become so widespread that any claim for addressing them is naturally suspect. And in fact, we ourselves don't claim to solve the problem. What we do is provide the tools so that your software development or IS team can quickly create solutions that are suitable for your own application or enterprise.

And this isn't surprising, because creating tools for software developers to solve their own problems is the foundation on which Desaware is built.

For notification when new articles are available, sign up for Desaware's Newsletter.