Re: PDW Q

What else can I do and where do you think I might be screwing up?

Good news: You are not the one screwing up<g>.

Where to begin?

Perhaps the quickest and silliest answer is not to use the PDW, use another
installer (Inno, Wise, MSI...)

That said...

When you run the setup app to install your program the very first this it does
is check for updated files on the target machine that setup will use to install
your app. Mind you, normally these files are not used by your app (directly
at least), but they are used by setup. Most of these files are system files,
so they are used indirectly. When you create your setup package a .LST
file is created. This file is text and you can open it with Notepad. In it are
sections and within the section are lines of data that describe the files that
will be installed.

When setup runs, it checks the first batch of files listed in the .LST file. It
compares the version number of each of the files listed against the version
number of the files that are currently installe don the target PC. If the target
PC's file are older, setup attemtps to update them for you. Ok, that's fine,
but there is one catch. Windows 2003 (among other versions) protect these
files against the very thing that setup is trying to do. When setup updates
these files it fails miserably, but really does not know about it so when it
finishes updating (or better said failing to update) it tells you that you need
to reset the PC. After this is done, and you run setup again, guess what
happens? Yup, exactly the behavior that you described.

... it doesn't name them, it only says "files" are out of date.

Not entirely true, it does prive the file name in a message box, but it is
buried under the other message box that gives you the bad news. When
you get the message box that tells you that you're screwed, don't close it,
instead ove it to one side. Start digging, hopefully you'll find the message
that gives you the file name.

To fix this you can try some things. Some have written that simply by
eliminiating the troublesome files from the .LST file has fixed this. I present
the section of the .LST file that usually causes this anooyance:

[Bootstrap Files]
File1=@xxxxxxxxxxxx,$(WinSysPathSysFile),,,7/15/00 1:00:00 AM,101888,6.0.84.50
File2=@xxxxxxxxxx,$(WinSysPathSysFile),$(DLLSelfRegister),,5/31/98 1:00:00 AM,22288,4.71.1460.1
File3=@xxxxxxxxxxx,$(WinSysPathSysFile),$(TLBRegister),,6/3/99 1:00:00 AM,17920,2.40.4275.1
File4=@xxxxxxxxxxxx,$(WinSysPathSysFile),,,3/8/99 1:00:00 AM,147728,2.40.4275.1
File5=@xxxxxxxxxxxx,$(WinSysPathSysFile),$(DLLSelfRegister),,3/8/99 1:00:00 AM,164112,5.0.4275.1
File6=@xxxxxxxxxxxx,$(WinSysPathSysFile),$(DLLSelfRegister),,4/12/00 1:00:00 AM,598288,2.40.4275.1
File7=@xxxxxxxxxxxx,$(WinSysPathSysFile),$(DLLSelfRegister),,8/18/01 7:00:00 AM,1388544,6.0.92.37

First, make a back up of this file! Done that, run setup and when the bad news comes
up, attempt to locate the file name of the "offending" file.Make a note of it. Now exit the
setup and open the .LST file, locate the file that caused the problem and remove the line.
Important! Note the "File1", "File2", etc. These must be consecutive. If you remove, for
example "File4=@xxxxxxxxxxxxxxx" you must edit the remaining "Filex" lines so that
they'll be consecutive. Rerun setup and repeat until the install goes ok.

I have never tried the above approach. What I do is make note of the files in the above list,
locate them one oby one, copy them over to some portable media and copy them back
to my development machine, but not (NEVER) to the System folder. Instead, I copy them
to the Redist folder:

C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\Redist

Depending on how you installed VS98 your folder path might be different. Of course it bears
mention that you should backup the contents of this folder. Now you can rebuild the setup
package. It will use and include the files that you copied over from the target machine and
the .LST file will reflect the correct version number (and other file specific data). You can now
proceed to run the setup on your target machine. When setup validates the version of the files
listed in the .LST file against the version of the currently installed files, guess what? They'll
match and setup will continue on its merry way.

Another cheat that I have used when desperate and my dev. machine is not available is to
recreate the setup package on site. To do this you need one additional file: makecab.exe.

My makecab.exe is here:

C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard

You might have to search for it. When you build your setup package and physically move
the files to your target machine, make sure that you take along this file. Notice that when
you build your setup package, there is a folder called support, take that with you too!

Now you are at the target PC and you get your first wake up call. Find the file that needs to
be updated and copy it to the support folder. Get its properties, like file date, size and version.
You can do this easily by right clicking the file and selecting Properties. Now open the .LST
file with Notepad and locate the offending file within the Bootstrap section. For example, say
that it was OLEAUT.DLL. Locate the line in the .LST file:

File6=@xxxxxxxxxxxx,$(WinSysPathSysFile),$(DLLSelfRegister),,4/12/00 1:00:00 AM,598288,2.40.4275.1
(sorry about the word wrap here)

Notice the date 4/12/00 1:00:00 AM, the file size 598288 and the version number 2.40.4275.
You will have to change these to the data that correspond to the file that you copied over from
the target machine. Frankly, this is a pain, it is crappy, error prone and an overall lousy way
to fix this, but if you are on site and don't have your dev machine handy.. it will be the only
way. Where was I? Oh yeah. After you have edited the .LST file save it. make sure that you
are editing the .LST file in the Support folder. Once that is done and saved locate another file
that will have a .BAT extension. That is the batch file that runs the makecab with the correct
parmeters. Open that with Notepad (click BAT file once, right click, select Edit from menu).
Notice that it has the path of the makecab file hardcoded in there. You'll have to change that
path to wherever you have the makcab.exe file. For example, if you created a CD with the
setup, Support and makecab files and you have the makecab file saved in the \MyAppSetup
folder, you would change the line to "d:\MyAppSetup\makecab.exe" , obviously taking care
to correctly reflect the drive letter of the CD drive on the target machine.

Once you have edited and saved the BAT file, you can run it. It will create a new CAB file
and a new LST file. Once that is done, make sure that both the CAB and LST files are on the
same folder as the setup. exe app. When I use a CD to transport the setup package, I copy
everything to the hard drive of the target PC and do my dirty work there, since I won't be able
to save any changes to the Support folder or files when they are stored on the CD. What you
are basically doing is creating the setup pakage manually over and over until all the file
conflicts are resolved. As I mentioned, this is a grueling process. I have read that some have
resolved this problem by downloading the lastest distributable files for VB6 and have installed
them when this problem comes up. Supposedly, this updates the system files that cause
this problem, but other factor have to be takeninto consideration, such as the SP level. I have
never tried this approach and even if I have read that it has been done, I can't guarantee
anything.

I hope my mega tome helps somewhat :-S

Regards
Saga
--



"Pop`" <nodoby@xxxxxxxxxxxxxxxxxxx> wrote in message news:nyEyi.1285$Uf7.510@xxxxxxxxxxx
Hi,

I've been playing with the VB6 SP6 on XP Pro SP2+ VB Pkg & Deploy wizard, and it works great on
this computer, the same one I did the development on.
However, when I turn around to my dual xeon processor win2000 Pro Server with an install CD, it
fails to install, citing that it can't continue due to out of date files. No surprise there;
they're all 1999 dates when I compare what's in the compile against the machine.

When running a compiled setup.exe, nothing is actually being copied and no directories are created
anywhere; nothing is installed, including the DLLs.
As I understand it, the "updated" .DLLs should have been copied to the \Program Files\my app\
directory, right?
I've opened the .CAB with Winzip and the DLLs are there.
On the off-chance I missed something, I rebooted and reran the setup two more times with the
same results every time:
Message that it can't continue because files are out of date, an offer to install them for me,
a very short pause while it flashes 'copying' on the screen, and another message saying to reboot
and run setup again. And the cycle repeats.

So ... since the directory structure is never changed at that point, where would it write the DLLs
to? They can't go to winNT system32 because those are in use. It looks like they should go to
the Program Files directory where my app will reside. But nothing at all is ever created under
Program Files.

I know, I could manually go ahead and copy everything to where I need it, but I'd rather make it
work "as advertised".
I've tried it with the files the compiler creates (cab, exe, chm) and from the Deploy button
too, with no difference in results. I've checked inside the .CAB and it seems to have everything
it needs.

It's almost like it's offering to update the files too soon, before there is a place to put them,
or it's not creating a place for them. Or, I'm misunderstanding and it's not really talking about
the DLLs; it doesn't name them, it only says "files" are out of date. It'd be easier to write a
command mode batch file to do this I think<g>!

What else can I do and where do you think I might be screwing up?

TIA,

Pop`






.

Quantcast