|Products Purchase Publishing Articles Support Company Contact|
support > Product FAQ > VersionStamper
Event Log Toolkit
NT Service Toolkit
Frequently Asked Questions
1. I use the VerParseWebPage1 object's ParseWebPageReturnXXX method to retrieve a file list from my web site and it returns an error. But, if I set the URL to the URL specified in the AutoUpdate or VsWebLst sample projects, it works.
The VerParseWebPage1 object uses standard HTTP 1.0 protocol to retrieve files from web sites. But, some web sites requires a "Host Header" to be sent along on a HTTP "GET" request (our web site does not require this header). Our component now sends that header along with every "GET" request. The VersionStamper files has been updated to take care of this situation, run the VersionStamper Update or contact Desaware to retrieve the latest file.
The other thing to be aware of when putting a file list on a web site is that the VersionStamper file list is a plain ascii text file. Be sure that you do not save it as a HTML file on your web site. Saving a file as HTML will add HTML formatting to the file which the VerParseWebPage object will not be able to parse.
2. I had VersionStamper scan my Visual Basic project and it returned the error "Run-time error '52'. Bad file name or Number".
Some ActiveX files stamp an unusual registration string in the registry. Normally, an ActiveX file would write the path of the registered file to the registry, but some also append an extra "\#" to the end of the path (the VB 5 run time was an example). This results in an invalid file or path. VersionStamper has been updated to take care of this situation, run the VersionStamper Update or contact Desaware to retrieve the latest file.
3. I use VersionStamper to implement an AutoUpdate for my application. But on certain systems when the files are updated, I get a "Path Not Found" error message.
This can occur if one of the files being updated is in use and the drive the file is located on does not have a "\Temp" folder. The new dwvslb?.dll (VersionStamper Component Library) files fixes this problem - run the VersionStamper Run Time Files Update utility to retrieve them (or contact us). Make sure your users get the new VersionStamper Component Library before updating the other file.
4. I am using the VersionStamper ATL control (dwvstp36.ocx) to embed a file list in VB 6.0 with SP 3. When I compile the project, Visual Basic crashes. The crash occurs at the beginning of the write phase of the compile sequence.
This problem has been fixed. You can run the VsUpdate.exe utility ("VersionStamper Run Time Files Update") located in your \verstamp\util directory to retrieve all the latest VersionStamper files. Or, if you have some type of firewall, we can send you the files - please give us the name of the person or company VersionStamper is registered under - if you have just purchased it, please tell us where you bought VersionStamper from.
5. When I parse a Wise Installation script file, I get a run time error - "Path Not Found".
Be sure that you are not using variables (e.g. "%SYSTEM%) in the Install file paths or Include Script paths. The VersionStamper Conflict Wizard does not support Wise variables defined in paths. Also, starting with version 8.14, when creating a new Wise Installation Project script file, an invisible "Include Script" item is appended to the end of the installation script file. This "Include Script" item includes the rollback.wse script file. But it also uses the "%_WISE_% variable in the script file's path.
You can either manually edit the script file with Notepad to change the Path using a full path, or to remove the "Include Script" item command from the end of the installation script file. You can also select the "Ignore Wise Include Script" check box to have the VersionStamper Conflict Wizard ignore all Wise include script commands.
6. I have VersionStamper 6.0 and I use the dwvstp36.ocx file to embed a list of files into my EXE to verify. I get a "Control does not have an embedded file list" message when I do a verification if all the files are correct. But when I have a file conflict, VersionStamper correctly identifies the conflicting file. I also ran VerResQ and it reports the same error message for EXEs with no file conflicts.
There was a bug in the VerResQ utility and the vervrfy.bas sample template file. The problem will appear when you use the embedded EXE method with the new VersionStamper ATL control and verify an EXE which does not have any conflicts. It will think that there was no embedded list. You can download the fix and replace the vervrfy.bas files located in your VersionStamper\Samples and VersionStamper\Template directories, and replace the VerRsq32.exe file located in your VersionStamper\Samples directory (vs_vrfy.zip). The following code snippet contains the code changes to the original vervrfy.bas file:
Sub LogEnumComplete(vsctl As VerStamp)
Replace the following code section:
'double check to make sure we scanned a file with 'embedded information If vsctl.VerifyMode = 2 Then vsctl.VerifyMode = 3 Else vsctl.ScanFile = FileToCheck$ End If
with the new code:
'double check to make sure we scanned a file 'with embedded information If FileToCheck$ <> "" Then vsctl.ScanFile = FileToCheck$ Else vsctl.VerifyMode = 3 End If
7. I have VersionStamper 5.0 and everything worked fine in VB 5.0. I'm now using VB 6.0 and VersionStamper's "Scan Project" button is hidden in the VersionStamper "Select Files" form. Is there a fix or update?
We have a "maintenance" release of VersionStamper 5.0 that will enable the "Scan Project" button in VB 6.0, it does not support scanning of the new VB 6.0 files, but it should work fine with project upgraded from VB 5.0. VersionStamper 6.0 which will have full support for VB 6.0 will be available probably in December. Please email firstname.lastname@example.org and give us your name and company name (or name of the person that VersionStamper is registered under) and we will email you the new files.
8. The "Scan Project" button is hidden in the VersionStamper "Select Files" form.
There are a couple of reasons on why this may occur. First, VersionStamper can only scan Visual Basic projects. This button will be hidden for all non-Visual Basic environments. If you have version 4.0 of VersionStamper and running in Visual Basic 5.0, then you need to upgrade to VersionStamper 5.0. VersionStamper 4.0 does not recognize Visual Basic 5.0 file formats. If you have VersionStamper 5.0 and running in Visual Basic 5.0, then you need to set the "Project Explorer" dockable option -- select the "Options" command from the "Tools" menu in VB, then the "Dockable" tab and check the "Project Explorer" check box.
9. VersionStamper does not seem to be doing the verification. What am I doing wrong?
Check how the verification was set up. The easiest way is to follow the "Quick Start" section in the manual or help file.
10. How to verify that VersionStamper will trigger an error for a particular file
I have a VersionStamper control on my form and filled out the version information properties and selected the files I want to verify. I followed the directions in the manual by adding the required files and code snippet. For testing purposes, I made sure that a conflict should occur by setting the date for one of the required files to a later date. But it does not find the conflict.
When testing a file based on the file's date/time, make sure the Compare File Date/Time and Older Version warning flags are checked in the Trigger Warnings frame. If you have more than one VersionStamper control in your project, make sure you are using the correct one. You can also select the Always warning flag so that it will always trigger the FileConflict event for testing purposes.
11. Other ways to use VersionStamper
Our application uses a file that does not have any version information, and we cannot check the file's date because people often change the date of that file. There is an internal structure in the file that we can read that will tell us whether we have the right file or not. Can VersionStamper help us?
Set VersionStamper's Always warn flag for that file. Then during the FileConflict Event, get the path of the file it found (this will be the file Windows will load) and do your own check on that file. An alternative is to check for the correct File Size, you may select a warning if the File Size is larger or smaller than the specified size.
12. Does VersionStamper work in Delphi?
VersionStamper will run under Delphi, MSC, Visual FoxPro, just about any VBX or ActiveX compliant platform. VersionStamper includes samples for use in Delphi and MSC in addition to Visual Basic samples.
13. Does VersionStamper search files in Windows95 differently?
In Windows95, VersionStamper does not seem to be searching for certain 16 bit DLLs according to the search flowcharts in the manual. I have placed these DLLs (the required versions) in the same directory as my application, but older versions also exist in the System directory. The shortcut that starts my application also sets the working directory to my application's directory. According to the manual, Windows will check the current directory before the System directory, but VersionStamper is reporting a conflict with the files found in the System directory even though it did not report these DLLs as being in memory.
There is a subtle new feature in Windows95 and it affects the order in which 16 bit DLLs are searched. When 16 bit DLLs are loaded from the System directory, Windows95 automatically creates a key in the registry for that file. Whenever an application wants to load a 16 bit DLL that is not already in memory, Windows95 will check the registry entry for that particular DLL first.
If it finds the DLL's file name there, it will attempt to load it from the System directory first, followed by the normal search orders. This is an undocumented feature (or scarcely document) that may change in the future. When running in Windows95, the 16 bit versions of VersionStamper checks the Windows95 registry to determine whether the specified DLL is listed there. If it is, VersionStamper automatically adjusts its search order to match that of Windows95.
14. Does VersionStamper 4.0 work in VB 5.0?
A. The 32 bit OCX control in VersionStamper 4.0 works in VB 5.0 without any problems. The only limitation is the 32 bit design time DLL. The DLL may not scan VB 5.0 projects correctly due to new file types, and may not include some of the required DLLs or OCXs used by the VB 5.0 project. These files may be manually added to the embedded file list. VersionStamper 5.0 includes support for VB 5.0 projects.
15. What are the differences between the VBX and OCX?
1. The ability to stamp a version resource is removed from the OCX version since VB 4.0 allows you to embed version resources.
2. The OCX version allows you to embed two lists in each control to verify (16 bit list and 32 bit list). This way, you can use the same control when compiling for 16 or 32 bit platforms. The 32 bit version of VersionStamper will always scan the 32 bit list, and the 16 bit version will always scan the 16 bit list.
3. The OCX includes a new method allowing you to specify the files to verify dynamically. Normally, the files to verify are specified during design time. This feature allows you to include code (or an external file) that will "build" a list of files to verify during run-time based on your customers system, license, etc.
16. Can File Manager or Explorer display version resource for VB 3.0 EXE files stamped with VersionStamper?
I use VersionStamper in VB 3.0 to stamp a version resource onto my VB executable. I enter some of the Version Resource properties of a non-Slave VersionStamper control. After creating the EXE, I use File Manager to view the version resource but File Manager or Explorer reports that there is no version resource.
File Manager and Explorer do not look at the version number for a file. Instead, they look for the version string (exeFileVersion property). If a file does not contain a version string, then File Manager and Explorer will assume that it does not contain any version information. In addition, the NT File Manager version has a bug where if a file has a version resource and the Product Version string info field (and possibly others) is longer than 15 characters, it will report the file as having no version resources, period. Use VersionStamper's VerInfo utility to retrieve the correct version resource from executables and DLLs.
17. VersionStamper is not stamping a version resource in my VB 3.0 EXE file
I am using the VBX version of VersionStamper in VB 3.0. I entered information in the exe* properties but when I compiled the executable, it did not stamp any version information in the EXE file.
First, make sure the "Slave" property is False on the control. Also, remove any programs that may be "subclassing" the Visual Basic environment. VersionStamper subclasses Visual Basic in order to determine when VB is done compiling the EXE file. Other "subclassing" applications may interfere with VersionStamper (especially if they do not use Desaware's SpyWorks to do their subclassing). Also, make sure there is enough disk space for two copies of your EXE. VersionStamper automatically makes a "temporary" copy of the EXE file in the "TEMP" directory. In cases where something "broke" VersionStamper's connection to the Visual Basic environment, you can close Windows or Visual Basic (in the case of VB, you'll need to use something like WPS or SpyWorks to unload the dwspydll.dll module - be sure no other programs are using it to avoid a GPF).
|Products Purchase Articles Support Company Contact