After testing an install of a program containing a ReSize control, ReSize is unable to locate the RESIZOCX.LIC development license.

Last updated: January 21, 2007

By default the ReSize install program places the ReSize OCX(s) in a directory other than \Windows\System. This was done to make the uninstall of the demo version of ReSize cleaner. ReSize follows Microsoft's standard OCX licensing scheme, which requires that a license file reside in the same directory as an OCX. The ReSize install program places RESIZOCX.LIC in the same directory as ReSize16.OCX and/or ReSize32.OCX in accordance with this standard. The ReSize install program also creates a reference to the location of the ReSize OCX file(s) in the system registry of your development PC.

When you run an install of your owown program on your development PC, a second copy of ReSize gets placed in the \Windows\System (\WINNT\System32 or \Windows\System32 on an NT machine) directory as part of the installation process. Since you don't distribute ReSize with the development only RESIZOCX.LIC file, only the ReSize OCX file is placed into the \Windows\System directory. The system registry is also updated to point to the new copy of ReSize that is in the \Windows\System directory.

The next time you run from the VB development environment, the system uses the copy of ReSize that is in the \Windows\System directory because that is where the system registry is now pointing. Since there is no corresponding copy of the RESIZOCX.LIC file in this directory, you get a message indicating that you are using a runtime only copy of ReSize.

Place a copy of RESIZOCX.LIC in the \Windows\System directory.
On an NT development machine place a copy of RESIZOCX.LIC in \Windows\System32 or \WINNT\System32 depending on the name of your main NT directory.

Philosophical ranting:
If you encountered this problem it is because you are using the same machine to test your installation as you are for developing. We recommend that you avoid doing this if at all possible. Testing installation programs is important. If you are working with a large user base, the cost of a failed installation can be high in terms dollars and also in terms of less tangible items such as your reputation.

The most common error an installation program is likely to have is the failure to copy all of the necessary files to a target machine. When you test an installation program on a development machine, most if not all of the files you are installing will already be present on the development machine. Your test will fail to detect that files needed by your application are not being copied by the installation program.

Another common problem with installation programs is the failure to register an OCX or to make other changes to the system registry. Once again, testing on a development machine will fail to identify these problems.

We recommend that you dedicate a machine for the sole purpose of testing installations. You need to keep a very controlled environment on the test machine. Each time you finish a test of an install program, you need to restore the test machine to its previous "virgin" state. You either need to reload all of the software on the test machine or perform some sort of reliable uninstall to completely reverse the process of your installation.

If your budget and resources don't permit you the luxury of using a dedicated installation test machine, then we recommend that you set up a development machine with a dual boot. Set up one partition for development. Set up the other partition with a highly controlled environment as outlined above for installation testing. Its possible to set up a dual boot without incurring any additional software or hardware costs (provided you have enough hard disk space), but you may want to investigate using several widely available utilities that will make the job easier. Partition Magic by PowerQuest helps you create and modify partitions without having to erase your entire hard drive. System Commander by V Communications, Inc. lets you boot into multiple operating systems or multiple copies of the same operating system.

Copyright 2007 by Larcom and Young.
All rights reserved. Revised: January 21, 2007.