[RESOLVED] Package and Deployment to Win7 64bit

A friend and I have over a period of more than two years developed a fairly complex VB6 program. It is mostly to do with Access databases and their interaction with Excel sheets.

The program has been written on 32 bit machines running under win98SE, win2000 and winXP. These have all worked fine. A package and deployment wizard was produced under on the Win XP machine running VB6 and this has been successfully installed on several other XP machines as a stand-alone program (ie. they do not have VB6 loaded to them).

So far, so good. Now there is a need to have our program run on Win 7 64 bit machines. However when we run the installation package it freezes. There is no error message - it simply stops part way through.

I realise that in the above I have provided little detail thus far.

The initial question please is whether there is some fundamental step which must be taken before a VB6 program (which will be 32 bit) can be installed on a 64 bit win7 machine?

I searched the forum for precedents, but whereas there has been quite a lot of mention of Win7 64 complications none seemed to cover our problem.

Suggestions and/or pointers to information sources would be appreciated please.

camoore
Wales, UK

I'd start by running the setup with elevated privileges and see if it makes any difference. Also, and I might be criticised for suggesting it, try turning uac off (just for the install)

I'd wonder what the setup.lst file might reveal.

Thank you Doogle and Dilettante. My chum is in a different time zone, so I will relay your suggestions and report results back to this thread.

Regards,

camoore

Wales, UK

Hi all,

I am camoore friend that is working on this problem. I had someone at another location try and install the program from a shared drive. He had full admin rights and the program froze during install, not sure exactly the point at which it did this and it will be a couple days before I can talk with him again. The deployment package was built from vb6 using a clean xp pro install.

We had no problems doing the install from a shared drive on the xp 32 bit machines, just win7 64bit.

Thank you,

George

I think that this should go in the Package & Deployment Forum of VBForums...

Quote:

---

Originally Posted by peorge9566

the program froze during install

---

Ask your friend to document where during the setup procedure the program froze and what his system specifications are. Not sure if the setup keeps a log of events or not? If it does might be worth checking in there to see why the setup failed then report back to this thread.

-- Try doing a Debug.Print of the Setup Software. Also try doing that inside the COM IDE, that way you can Step Debug and then that is much more easier to deal with when debugging the software that you or someone else has written!!

ThEiMp is probably correct in saying that I should have posted this thread to the Application Deployment section of the Forum. Perhaps the moderator will transfer it to there. However package and deployment to Win7/64 is/will become increasingly necessary, so most VB6 programmers are likely to be interested in problems encountered and solutions found thereto.

It would be interesting to hear from anyone who has been successful in deploying a VB application to Win7/64 using the VB6 Visual Studio Package and Deployment wizard. At least that way we would know that there is not some fundamental problem, and therefore that our difficulty arises either from some aspect of our program or from the manner in which we are trying to deploy it (eg. via a shared drive).

My friend peorge9566 will respond to the technical suggestions kindly advised above by ThEiMp and Nightwalker83. Neither he nor I has a win7/64 machine close at hand, but the problem has been encountered at a third location in peorge's neck of the woods - which is USA.

camoore

Wales, UK

Thread moved to the 'Application Deployment' forum (thanks for reporting it to us Nightwalker83 :thumb: )

Thank you for the transfer Si.

It was in fact ThEiMp who suggested this.

So it was, but mentioning it in a thread doesn't let the moderators/admins know about it - which means there is a good chance we wont notice, because we don't necessarily read every post on the site.

Reporting something via the link on the left of posts (as NightWalker did) means that we definitely know about it, and that we find out much sooner than we would otherwise.

All duly noted about the thread etc.

Now can you assist with the problem please? Invariably your particular expertise and tutorials have proved of much use to us.

camoore

Wales, UK

I haven't used P&DW for a very long time, so I can't really help with it unfortunately.

All I can comment on is:

Quote:

---

Originally Posted by camoore

The initial question please is whether there is some fundamental step which must be taken before a VB6 program (which will be 32 bit) can be installed on a 64 bit win7 machine?

---

Apps which just need the VB runtimes worked without any installation, and apps packaged with VSI worked fine... but that isn't much use here.

Quote:

---

Originally Posted by peorge9566

He had full admin rights and the program froze during install,

---

Was the setup run as an admin (by right-clicking and selecting that option)? Starting with Vista, being logged in with admin rights does not mean that things get run as admin.


Also, I recommend showing the setup.lst file as was hinted earlier.

What kind of Service Package version RunTiime are you running on your install disk & machine???

Will await response to these points from peorge9566, who is closer to the problem. This may take a day or two, due to shift work patterns. Thank you.


camoore
Wales, UK

I will have the admin that had the failed install send me the log. The general deployment package does write a log, I'm just not sure how far he got during the install process. I will try and get this info tonight at work ad post tomorrow morning.

Thanks for all the input.

Peorge

You're welcome: Fellow VBForum's member...

Peorge9566 and I apologise for the delayed response to posts, for the which we thank you.

This was due to peorge suddenly getting a requirement to relocate for his work about 1000 miles, and he has been ultra-busy with that issue ever since.

In Wales, however, I have been able to make some progress in that a local chum has just installed a clean Win7/64 OS.

Using the Visual Studio Package and Deployment Wizard, I produced a deployment package for our program (on a Win 98SE machine). I will not clutter this post with details, but whenever the process caused me to make a choice about file issues and so forth I simply made what seemed the most logical. The package was duly produced with no errors/glitches/hang-ups.

Via a memory stick, I took the deployment package to my chum's Win 7/64 machine and ran it (ie. ran the install.exe). For the most part the whole package install ran just fine. I got two error messages (one about DAO350.dll and the other about MSADOX.dll). These messages asked me to ignore or try again. I selected Ignore, and continued. A few other messages came up warning me that certain files I was trying to install were of an earlier version than those on the Win 7/64 machine. At each warning I elected to stay with the (later) version on the machine.

The install completed. At initial testing of our program under Win 7/64, everything seemed to be working "perfectly", though it is a large complicated program and it will be some time before all possible gremlins - if any - are exposed.

The important lesson (for us) at this stage is that a VB6 32 bit program CAN be installed onto a Win 7/64 machine using the Visual Studio Package and Deployment Wizard and that it seems to work fine.

An interesting feature (for me) of this install was that the receiving machine did not have MS Access or MS Excel loaded, yet our program ran well reading from, manipulating and writing to both Access and Excel files which were contained within the data files folder which accompanies the program (which was separately loaded to the C-drive of the receiving machine as opposed to being any part of the deployment package.

When he has time, peorge will doubtless investigate further why his P&D process hung up on Win 7/64, but at least I have established that the P&D Wizard IS capable of generating a deployment package which appears to work OK with Win 7/64.

camoore

Wales, UK

-- hehe ,, I forgot about the Package and Deployment Section of the Visual Studio Wizards!!

Quote:

---

I got two error messages (one about DAO350.dll and the other about MSADOX.dll). These messages asked me to ignore or try again. I selected Ignore, and continued. A few other messages came up warning me that certain files I was trying to install were of an earlier version than those on the Win 7/64 machine. At each warning I elected to stay with the (later) version on the machine.

---

These are telling you important things.

In many cases it means you are trying to deploy things that should not be deployed such as MDAC components, VC runtimes, etc. The messages are due to Windows trying to protect itself from a "broken" installer.

There are two ways to handle this using the PDW. Both mean you need to read the 14 years of MS KB articles on the subject since VB6 was released.

One is to update VB6DEP.INI (in the PDW's folder) to tell it what things it should not try to deploy anymore. The other way is to manaully exclude these items each time you use the PDW. Knowing what to do in both cases means knowing what those MS KB articles told you.

Best practices for deploying Visual Basic 6.0 applications is one "gateway" article to get you started.

What if it is possible, to modify a section of the ini file, that making it only for the current installer and not all of the other installers on the current machine??? I have been able to read up on some of the white papers, that are on visual studio installers and then got this kind of information from them: "You are able to totally modify the installer that comes with visual studio, but then that isn't touched on how to do it. Rather more over, to what to add and then what to remove from it, as such and the like...

Are you talking about packagers (like the PDW, or the thing called "Visual Studio Installer" which is a packager)?

In any case VB6DEP.INI is only used by the PDW, much as its Redist folder is.

I have no idea what you mean by "total modification" either.

If you are using VSI 1.1 to package VB6 applications as .MSI packages you have a great deal of flexibility, but not complete flexibility. There are some Windows Installer features that it doesn't directly support.

For those features you usually need to use a more complete 3rd party packaging tool or else you have to edit the .MSI database (yes, MSI files are databases). You can do this using Microsoft tools like Orca.exe or a custom WSH script or a VB6 program. A script or program can make changes that you might need when you rebuild repeatedly because these can open the MSI database and update it.

The PDW creates what are called "legacy scripted installers."

MSI and related files are processed by Windows Installer, an OS service. You can find a lot of details about this at About Windows Installer.

A gateway article on VSI 1.1 might be How To Create a Visual Basic Installer Package with Visual Studio Installer. Also Using Microsoft Visual Studio Installer for Distributing Visual FoxPro 6.0 Applications has much useful info even for VB programmers.

There are also a few 3rd party "for dummies" overview writeups like Create installations with Visual Studio Installer.

I thought that everyone (programmers rather, more over) had forgotten about the many long nights working with FoxPro on the Office v4.5 platforms in Windows v3.11!! Yes, we still got those to work through, but then they were seemingly taken off our hands, and then someone else took up the job of making them go into the next century. SQL, I guess...

Also I will never mutter a command or string of it, because of the dirt of the old age of technology, that it is...

Actually I think VFP got new versions up to 9.0 or so, unlike VB. So we're probably the ones mucking about in the "dirt of the old" here. ;)

An old friend of mine still uses Microsoft QBASIC version 4.5 for DOS6.22!!

I guess that one version was the first internal native compiler, that came with IDEs, at the time???

QBasic is an interpreter that came with DOS (and with Win9x, and I think even Win2K).

QuickBasic was the DOS compiler and IDE, and it compiled almost identical program syntax. VB for DOS 1.0 was actually the last version of this compiler as far as I can tell, adding a sort of DOS-mode GUI to Professional Development System 7.x, the prior version.

hehe ,, that's going back abit, don't you think???

Yeah, way back. Before my time actually. I wasn't using Microsoft PCs much back then, in the days when there was more computational diversity.

However I put in some time in the '90s maintaining some creaky old DOS programs.

1991': I was using 8-Bit dBase IV, QBASIC and then some sort of Excel Standoff-ish thing for school/home work. But then we went to an upgrade to 32-Bit typed based machines, in the late 1997'...

I apologise for not having responded to recent posts into this thread. For some reason I did not receive e-mail notifications of them from the Forum.

The suggested reading by Dilettante at post 21 above was most helpful. This pointed me to the following URL :

http://support.microsoft.com/kb/830761

Reading this, I have learnt these points :

1. It is best that you build a deployment package on a clean-install machine running the same operating system as that for which the package is destined.

2. That you should carefully evaluate any deployment package on as many equipments as possible prior to its distribution to check for glitches. (in our case, we had no problen at all with deployment to Win XP machines, but encountered problems with Win 7/64)

I have, since starting this thread, shown that our program CAN be deployed to a Win 7/64 machine, and hence that there is no fundamental incompatibility between Win 7/64 and a 32 bit VB6 originated program.

The problem which my friend peorge has encountered must be a "localised" one and something which we will need to fix locally. I doubt that its details will be of interest to the Forum further.

In that this thread appears to have generated a deal of interactive posts, I will leave it open for a while, but believe that our initial query has been resolved.

Thank you, Dilettante and tHeImP.

camoore

Wales, UK

-- Hehe ,, don't mention it. I was doing my job. I'm always on duty!!

Thank you very much to all who have contributed to this thread.

It has served to prove to me that there is no inherent reason why a VB6 32 bit program can not be deployed by the Visual Studio Package and Deployment Wizard to a Win 7/64 machine. However the various suggestions and advice in the posts above should be considered carefully.

At post #23 Dilettante makes reference to a MS article relating to the Visual Studio Installer routine (VSI) which is an alternative to the P&D Wizard. This article is most useful, and can be found at :

http://support.microsoft.com/kb/263739

I have VSI 1.1 (but found it particularly difficult to find a download source of it some time back). It seems that MS ceased to make it available through their website(s).


Will mark this thread as closed. peorge and I will need to investigate the particular reason for his 7/64 installation problem. If we find something of general interest, we will add a post here or start a new thread.

Thanks again, as always, for Forum assistance and support.


camoore

Wales, UK