Re: bootstrap and standard vb library installation questions
- From: "MikeD" <nobody@xxxxxxxxxxx>
- Date: Mon, 24 Apr 2006 19:33:04 -0400
"John S" <nospam> wrote in message news:eJIRry3ZGHA.3832@xxxxxxxxxxxxxxxxxxxxxxx
Hi All,
I need advice from you about bootstrap files and vb library
installation.
My app is developed using VB6 sp5 on W2K Server sp4 and I want to
distribute it to other computers with various Windows versions
(98, ME, W2K Pro, XP). First, I use PDW to collect
information about the files to distribute. Next, I will use Inno setup.
My questions :
a. Why PDW always read old files from directory
Program Files\Microsoft Visual Studio\...... ?
Why not from WINNT\System32 that contains newer version ?
Because that can get you into trouble. Chances are, you've got newer files in System32 that if packaged and installed on older versions of Windows will hose that older version of Windows. The versions that exist in the Redist folder (I assume that's what you meant with "Program Files\Microsoft Visual Studio\...... ?", but since you cut it off, I can only guess) are older versions but new enough to work and not cause problems on older versions of Windows.
How do I solve this so that PDW read from WINNT\System32?
Don't even try (but all you need to do is delete the file from the Redist folder, but I DON'T recommend that). Inno Setup is written so that it won't even include files directly from System32 (and a number of other folders as well). If you want to use a file from System32, you have to copy the file elsewhere and then point Inno Setup to wherever you copied it. This is a very good precaution that you should follow.
b. Before installation, the target machine may contain the
same files as mine, with older or newer date. If this
happens, what should I do ? Should I replace them or not?
How to make setup program not replace newer files on the
target machine ?
Any decent installer will already be written to deal with that situation. Generally, file dates are a last resort to determine if a file to be installed is older/newer than an existing file. File dates are not reliable because they are easily changed. Instead, the file's internal version number is used, if it exists. For example, the Setup program for PDW uses these rules in this order:
1. If the packaged file and the existing file both have version information, the version information is compared and the file with the higher version number "wins".
2. If the packaged file has version information and the existing file doesn't, the packaged file "wins".
3. If the packaged file DOESN'T have version information and the existing file DOES, the existing version "wins".
4. If NEITHER file has version information, then AND ONLY THEN, are file dates compared and whichever file has the more recent date "wins".
IOW, version information always has priority over file dates. You only ever get to comparing file dates if neither file has version information. This is why it's critical you properly increment the version number in your VB projects (you do this in Project Properties on the Make tab). If you compile a new version of say a DLL and don't increment the version number, the new version of your DLL won't get installed because it has the same version number of the existing DLL file, even though it probably has a more recent file date.
NOTE: the version of Setup1 that originally shipped with VB6 has a bug in which the OLDER file replaces the NEWER file when file dates are compared (it compares the dates incorrectly; it used DateDiff, but it had the two dates reversed in the function call). This got fixed in one of the service packs for VB6. I'm not sure which, but it was one earlier than SP5 (and since you have that, you don't need to worry about it). Actually, maybe this was a VB5 bug in its Setup1 program. I don't recall for sure. I just remember that some version of the Setup1 program had this bug.
Is it good to use the newest file only in my setup
package ?
No, not always. This is particularly true if your app will be installed on versions of Windows earlier than the Windows version under which you package the app.
c. I found an error message when running my setup file
created with PDW. "Setup connot continue because some
system files are out date on your system. Click OK if you
would like setup to update these files for you
now........" I clicked OK and restarted the computer
but the files in the target machine did not change.
The files in my setup package was older. How to solve
this ?
This is a known issue with a PDW-created Setup. SP5 should have fixed this by copying "proper" files to the Redist folder. But there are still other causes of it. See the following:
PRB: Multiple "System Files Are Out of Date" Errors
http://support.microsoft.com/default.aspx?scid=kb;en-us;191096&Product=vbb
d. I found an error message when running my setup file
created with Inno setup. "Unable to register the DLL/OCX:
GetProcAddress failed, code 123" This pointed to
MSVCRT40.DLL. What causes this ?
Is this problem caused by my old file that will be
installed ?
That's not an ActiveX file and therefore doesn't need registered. Modify your InnoSetup script to NOT register this file.
--
Mike
Microsoft MVP Visual Basic
.
- References:
- Prev by Date: Re: 2D graphics & speed quest
- Next by Date: Re: Why listview is better than DataGrid
- Previous by thread: bootstrap and standard vb library installation questions
- Next by thread: Re: bootstrap and standard vb library installation questions
- Index(es):
Relevant Pages
|
