[RESOLVED] Setup Program Problem - system files are out of date on your system

Hello.

I've written a program in VB6, and installed it successfuly on one PC. When I try to install it on another PC, the setup program gives me the message:

"Setup cannot continue becuase some system files are out of date on your system. Click OK of you would like setup to update these files for you now. You will need to restart Windows before you can run setup again. Click cancel to exit setup without updating system files."

I click OK and then re-boot, but when I run setup again the same message appears.

I used the VB6 packaging and deployment wizard to create the setup program. The program I'm trying to install uses an AS/400 ODBC connection, but other than that it doesn't use any unusual objects. I've created setup programs for several other VB programs I've written, and never had this problem.

The development PC is:
-Lenovo ThinkPad
-Win XP Professional, SP3
-VB6 SP6

The PC I'm installing my application on:
-Lenovo ThinkCenter
-Win XP Professional, SP2


The other PC that I successfully intalled the application on is identical to the one where the setup program is failing, but is in a different location.

Does anyone have an idea what I might try to fix this?
Thanks.

Mark.

Seach in "Application Deployment" under "General" here for threads on this topic.


There are several possible causes of this problem, but often it boils down to a setup package trying to deploy a non-deployable dependency.

This happens often with the PDW because it relies on DEP files and the [Do Not Redistribute] section of PDW's own VB6DEP.INI file to know which libraries should not be deployed. Since PDW is old, Microsoft seldom updates (or even provides) DEP files anymore. Since many dependencies are now OS-dependent, VB6 Service Packs cannot update VB6DEP.INI universally - so for many libraries they don't update it with new info.

You need to either update these dependency guidance files or (more likely) know which found dependencies to "uncheck" in PDW when defining a package.

Again, look for those other threads. But...

Even if you think two machines are "identical" some other application might have been installed that altered the environment on one machine. It might also be true that one machine has critical Windows settings altered (often relating to Windows File Protection). One might be at a later OS Service Pack or patch level. Lots of possibilities.

Thread moved to Application Deployment forum, which is where questions about installing/distributing your software belong

There is an article about this issue in the FAQs at the top of this forum, it may be useful for you.

this problem often arises in visual basic application installation. before you install the visual basic application in to a pc install "mdac" in to that pc and try installation. if it is a windows 98 system then you have to download mdac for 98. this may solve your problem. if you are using windows 98 then email me at [email protected] for mdac for windows 98 .

Thank you both for your help.

I generated a dependancy list using PDW, and here's what it gives me:

===================

[Version]
Version=1.0.0.1

[CologInterface.exe <0009>]
Dest=$(AppPath)
Date=11/7/2008
Time=16:44
Version=1.0.0.1
CABFilename=CologInterface.CAB
CABINFFile=CologInterface.INF
Uses1=msvbvm60.dll
Uses2=OLEAUT32.DLL
Uses3=OLEPRO32.DLL
Uses4=ASYCFILT.DLL
Uses5=STDOLE2.TLB
Uses6=COMCAT.DLL
Uses7=shfolder.dll
Uses8=MSRDO20.DLL
Uses9=TABCTL32.OCX
Uses10=COMDLG32.OCX
Uses11=MSCOMCTL.OCX
Uses12=comct332.ocx
Uses13=ReadMeBeforeFirstRun.txt

[shfolder.dll <0009>]
Dest=$(WinSysPath)
Date=4/13/2008
Time=19:12
Version=6.0.2900.5512

=====================

The CologInterface and ReadMeBeforeFirstRun files are files that I'm distributing.

I used a dir /s comand to look for all of these files (except my two) on the target machine, and they all exits in the windows\system32 directory.

Does this meain that I can exclude them from my setup distribution?

Thanks.

Mark.

It depends on the versions - if the version of the file on the target computer is the same as (or higher than) the version on your computer, you should be OK to not install them (higher versions aren't guaranteed to be compatible, but usually will be).

To check the version of a file, find it in Explorer/My Computer/etc, then right-click on it and select "Properties".

my dear friend there is another solution for your porblem. Open setup.lst file in note pad and delete the files under the heading Bootstrap Files and save it and try installation.it wil work

RDO is truly ancient, but if you must use it see the redist instructions at INFO: Deploy database applications with the Package and Deployment Wizard (PDW).

SHFOLDER.DLL is part of the OS in newer versions of Windows (i.e. since Windows 95; Windows 98; Windows NT 4.0). If you must redist it to one of these ancient OSs use Platform SDK Redistributable: ShFolder DLL. There is no clean way to deploy this from within a PDW setup without modifying Setup1 to recognize it and run it somewhat similarly to the way Setup1 looks for MDAC_TYP.EXE as a special case. However if you take these steps and Setup1 runs the ShFolder.exe as required, it detects any later ShFolder.dll already present and terminates with no action rather than overwriting the "better" one already in place.

Quote:

---

============
ShFolder DLL
============

The SHFOLDER.DLL may only be redistributed as part of SHFOLDER.EXE. You may
not redistribute COMCTL32.DLL except by using SHFOLDER.EXE. You may not
modify SHFOLDER.EXE

SHFOLDER.EXE is a self-extracting executable that will install the SHFOLDER.DLL
only if there is not a more recent version of the SHFOLDER.DLL in the system
directory. SHFOLDER.EXE will write the registry keys required by SHFOLDER.DLL.
SHFOLDER.EXE may be used on Windows NT 4.0, Windows 95, or Windows 98.

In addition to the rights granted in Section 1 of the Agreement ("Agreement"),
with respect to the SHFOLDER Redistributable Code,
you have the following non-exclusive, royalty free rights subject to the
Distribution Requirements detailed in Section 1 of the Agreement:

(1) You may distribute SHFOLDER.EXE

---

Thank you all for your help. I installed SP3 on the target WinXP machine, and the program installed without much complaint. It did tell me that the shfolder.dll file could not be regsitered, but the program runs fine.

I know that RDO is old, but it runs fine and does all of the basic SQL IO that I need. What would be the current DB access method? ADO?

Thanks again.

Mark.

RDO was an adapter technology for using ODBC prior to VB6. It was retained to make it easier to upgrade old VB4 and VB5 programs to VB6 without rewriting.

Developers were encouraged to write new VB6 programs using ADO with OLE DB instead of DAO and RDO with ODBC. It doesn't mean the older technologies don't work and don't have their place, it is just rarer to see them 10 years later.

Has anyone published a listing of all the required (recommended) updates to VB6DEP.INI ?