[RESOLVED] P7D Wizard says dependecies information out of date

[aztrix]

whenever i use P&D wizard to create a setup for my application, i keep getting errors saying things like;

"Dependency file information out of date click next to continue"

any solutions to this?

[RobDog888]

It depends on the dependancy file in question. The obvious would be to update your dependant file.

Thread Moved

[aztrix]

no dependecy information for these.......

dao360.dll
EXCEL.exe
imghelp.dll
MSACC.olb
msado27.tbl

and how would i go about updating these files? dependency information out of date..............

comdlg32.ocx
mscomctl.ocx
msstdfmt.dll
scrrun.dll

will continuing without updating this information harm my appliaction? how do i fix this problem?

[aztrix]

ok so i continued without updating and finished the setup construction.

went to standalone machine without any vb installed on it to test and got this error when running through the installation:

"Setup cannot continue due to some files are out of date on the system. click ok to update files or cancel to exit."

->> click ok then

"Computer must restart before setup can continue."

->> restart computer then start setup again and the same errors return, i can't move any further and complete the setup. i keep getting the errors.,

i have noticed that the first one appears when installing "msvb60.dll"

not sure if this is related to the first complaint i made above????

[RobDog888]

You can not redistribute any Office applications. it is illegal and a licensing violation to do so. You are redistributing DAO and ADO? Why are you using both in your app? DAO is unsupported and discontinued. Use ADO

[aztrix]

hmmm i agree it is illegal without the correct licensing. i have an export function in my app that allows the user to export all the information to excel. i did not mean to redistribute excel it just came up in the list somehow???

to remove any of these dependencies do i simply uncheck them from the projects references? i know i used dao at the start of the ptoject but ran into trouble and changed them ALL to ADO so i know i am not using dao anymore but how do i remove it?

[randem]

Just do not include Excel in the installation package. I find it strange that MS would create an installer then let it attempt to distribute their software which would be illegal...

For DAO just deselect it from your references.

[RobDog888]

Not only is it against the license and illegal but what if you install Excel 2003 on a system that has Excel 2007 or some other version? You really want to take a chance of messing up your customers workstation?

For the P&D Wiz to keep track of MS licensing guidelines would be absurd. Come on Randem.

[randem]

Why would that be absurd. They did know that they created Excel when they created PDW or was that a surprise to them? A simple list would be all that would be needed...

[RobDog888]

Oh sure, just have a list of thousands of programs and different versions to keep track of. What a nightmare that would be. I'm sure your program doesnt do that either.

[randem]

What versions Did the name Excel change with every version, cause I forget...

My program does maintain a list. Once a program name is added it will not distribute that application.

I am smarter than that...

[RobDog888]

I'll reserve my comments as this is getting off topic.

[dilettante]

Excel is there because the program is foolishly early-binding to Excel for automation. Go back and remove any reference to Excel and its Object Model and change all Excel object declarations to As Object and replace all New xxx.yyy with CreateObject("xxx.yyy"). Office programs change their automation class IDs every version, so you never want to early bind except during development. This is why we have conditional compilation in VB6.

INFO: Use DISPID Binding to Automate Office Applications Whenever Possible

Using early binding and late binding in Automation

Using Conditional Compilation

The rest in the 1st group are system components and you supposed to know not to deploy them. If you need to deploy the MDAC components in this list to a downlevel system (prior to Win2K):

The PDW does not distribute mdac_typ unless there is a specific reference to an ADO Library (any version) in the project.

You can also add mdac_typ.exe manually by clicking Add in the Included Files dialog box when you run the Package and Deployment Wizard. The wizard uses the MDAC_Typ.exe file in the ...\Wizards\PDWizard\Redist folder.

But note:

The installation of Microsoft Data Access Components (MDAC) requires that DCOM be already installed on the destination computer:

• For Windows 95 computers, install DCOM95.
• For Windows 98 computers, install DCOM98.

How To Control Which MDAC Version the Package and Deployment Wizard (PDW) Distributes

BUG: Error "Unable to Register MSADO15.TLB" If You Use a PDW Package to Install a VB Application


In the second group the last two are system components, and you don't deploy them. The comdlg32.ocx and mscomctl.ocx dependecies require deployment. To correct your out of date dependency info you must open their .DEP files and correct the versions and creation dates.


However...

It appears that you are trying to package your installed system copies of these libraries. You are normally expected to place deployable libraries and .DEP files into the PDW's Redist folder.

As far as I can tell Microsoft does not provide the latest set of standard VB6 dependencies anymore except as a set of Installer merge modules. Merge Modules for Service Pack 6 for Visual Basic 6.0 and Visual C++ 6.0. To use these files with PDW it is necessary to extract the contents of each merge module using the Orca.exe utility. The process is covered in the Orca Help. Since Installer does not use .DEP files you'll get none from this source and will have to create them or add the info to VB6DEP.ini.

Speaking of which, you're also supposed to update PDW's VB6DEP.ini over time. There has been a lot of water under the bridge since 1998!

I get the impression most users just punt, and let PDW package from System32 (shudder).

See: Best practices for deploying Visual Basic 6.0 applications.


<old fart rant>What the heck are they teaching kids in school these days? In my day we were expected to read the manual.</old fart rant>

Somebody should write a book, and maybe a few scripts to help auto-update everything. Oh, they did. Too bad they're all out of print.

So much for my advice. I'll bow out again and let the deployment experts have at it. (Waves cane in the air erratically and wanders off muttering..)

[aztrix]

dilettante, thanks for your comments. i have come to realize that packing and deploying my application is a little more complicated than i had ever imagined.

[dilettante]

The simple and "often works" approach is to simply unckeck (in the PDW) all of those dependencies except comdlg32.ocx and mscomctl.ocx and make sure you have a new enough MDAC_TYP.exe in the PDW Redist folder.

If PDW doesn't pick up MDAC_TYP by itself add it manually as suggested in one of those KB articles. Personally I never try to package MDAC because today it is the user's responsibility to update MDAC as part of OS updates.

Then ignore the "out of date dependency" warnings from PDW.

[aztrix]

i read all about the late binding thanks Dilettante. i removed the reference to the excel 10.0 object library from my project references and modifies my code for late binding to excel. but now i get a "User type defined not defined" Error when i try to export data from the database to an excel worksheet.

the line of code that triggers the error is;

      Dim WB As Excel.Workbook

the code immediately before this is (for late binding);

      Dim xlApp As Object
      Set xlApp = CreateObject("Excel.Application")
      xlApp.Visible = True

so how can i erase this error?

[dilettante]

You have to declare all of these objects as Object.

[aztrix]

im not sure how to do this code wise, can you please give me an example
what am supposed to replace and what with?

[aztrix]

never mind i worked it out cheers for your help tho