Building exes.....

[pmcdaniel]

Here's something I've never done before but have heard it's not easy.

Here where I work I have been given permission to create a front end (VB 6) for someone in another department. What do I do to create the exe and deploy it on another machine? It'll probably start off on this individual's PC but may eventually be used on a network so knowing how to do both would be very helpful. This person does not have VB on their machine.

It'll be accessing SQL Server and have several References such as OLE, ActiveX Data Object, Scripting, VBA and Excel to name a few.

I'll need to have some kind of explanation as to how I'll be doing this. I would love to just try to do everything myself but it's not like I can take up time on this other person's PC experimenting.

Any advice?

 

[HughLerwill]

You should investigate use of the Packkage and Deployment Wizard which may be available via the VB6 IDE - Addins menu. If it is not use the Add-in Manager option to make it available.
The Packkage and Deployment Wizard is not regarded as the best installer available but it should get you started.

 

[BobRodes]

Personally, I wouldn't use the P&D wizard, because there are too many situations where it doesn't work. In particular, if you attempt to overwrite a dll that the system is using with a newer version, your install will get caught in an endless loop, part of which is restarting your machine. I would investigate the Microsoft Windows Installer.

For more on the ancient woes of using the P&D wiz, see thread222-561173.

Bob

 

[dilettante]

The other obvious alternative is "Visual Studio Installer 1.1" which was provided as a replacement for the PDW back around 2001 as a replacement for VSI 1.0 (1999?). VSI 1.1 is a simple IDE for creating Windows Installer packages (.MSI, .MSM, etc.) and it is still a free download for VB6 Pro/Enterprise users today. It includes a wizard to help automate the creation of simple VB6 packages.

For packages more exotic than VSI 1.1 can create alone you can always turn to Orca and the other MSI tools as a supplement. Where to find Orca, the MSI editor tool, in the Windows SDK. You can even script Windows Installer components for repetitive MSI customization beyond what VSI 1.1 does on its own, or write a VB program to handle such chores.

Beyond that there are commercial packagers you can license as well. I'd avoid the ones that create a setup EXE instead of MSI packages, but some people seem quite happy with them even though Vista turns its nose up a bit at them just as it does PDW setups. For unsupported OSs (prior to Win2K) you need to be sure Windows Installer has been installed on target machines in order to use MSIs though.

Using VSI 1.1, reg-free COM techniques, and a supplemental script it is even possible to create per-user installer packages for your VB6 programs that will install into Vista without requiring administration elevation. The user never see a prompt at all.

Reg-free COM can also allow many VB6 programs to be XCopy-installed into XP SP2 or later.


You'll want to test any installation packages you create, no matter what installation technology you choose. I find that this is much easier by running a prepared standard OS image under Virtual PC than constantly re-imaging the hard drive of a test system.

 

[BobRodes]

<"Visual Studio Installer 1.1"

Sorry, that's exactly what I meant to say. I also hear a lot about INNO setup on these forums, although I've never used it.

 

[strongm]

>there are too many situations where it doesn't work

I just thought I'd butt in and say that, whilst the P&D wizard is a relatively simple tool and some people have found it doesn't always work for them, I've never had a problem with it.

Just recently I installed a program I wrote and originally packaged with the P&D wizard over 10 years ago (although to be fair, I think the package I actually used only dates from about 7 years ago) ago on my new Vista Ultimate box, and it had no problems whatsoever ...

 

[dilettante]

I'd agree with that.

Most of the problems with PDW setups have to do with their lack of support for Windows Installer functionality. That's generally not a concern unless you're in a corporate setting where you want to do managed installs, or you want an installer to do per-user installs for non-admin users in a locked down environment.

This isn't a PDW problem, since all of the tools that produce setup EXEs have the same limitations.

Another snag is that PDW calls DLLSelfRegister (just as regsvr32 does), which prevents you from properly versioning registered components for late binding. This is fairly exotic though.

Finally, often people fail to put redist components into the PDW's redist folder. This includes the MDAC package, which PDW's setup will handle for you. There is also a hack (can't find the KB article right now) for modifying Setup1 to install the Jet 4.0 package that was separated from MDAC around MDAC 2.5 or so. All of this is really for unsupported OSs (prior to Win2K) though really. One might want to "slipstream" other things this way like Windows Scripting for those older OSs too.

Aside from those sorts of issues I think the PDW generally works just fine.

 

[BobRodes]

<Aside from those sorts of issues I think the PDW generally works just fine.

I raised an issue in my old thread that I don't believe you've addressed, dilettante (although perhaps your "fairly exotic snag" is addressing it to some degree). When actually trying to use the PDW to deploy a for sale application several years ago, I had serious trouble with it.

While I haven't visited this for some time now, my current understanding of the situation is this: the PDW was designed at a time when an application which deployed a newer version of a system dll would be allowed to register that dll, and it would take the place of the existing one upon restarting the system. Hence the system startup requirement during the installation. New dlls would go into a registry location and be registered upon startup. That of course became a dll hell problem, so it wasn't long before system dlls could only be replaced by service packs. PDW would go on its merry way attempting to register the new dlls, wouldn't succeed, and would require that you restart the system to try again. This would be an infinite loop, unless you exited the install.

I would amend the suggestions I made then to say that pdw ought to work ok if there are no dll's that are loaded on system startup included in the package. If there are, you will run into the problems I describe there. Strongm, perhaps you can comment as to whether you have any of this sort of dll in your package.

Bob

 

[dilettante]

Maybe:

PRB: Setup Cannot Continue...System Files Are Out of Date

PRB: Multiple "System Files Are Out of Date" Errors

I've never seen either one myself.


FIX: Setup Program Created by PDW Disables Windows 95/98/Me System

Is similar, and mentions that the problem (and I assume the two above) were fixed long ago by a service pack.

 

[BobRodes]

Not quite. But maybe:

thread222-561173

This describes the problem pretty well. Although it's been around a while, I don't believe the problem has been resolved.

 

[strongm]

The package I described doesn't contain any DLLs that match your criteria, Bob. But I have to say, like dilettante, that I've never run into the problem you describe on any of the stuff I've packaged with the P&D Wizard

 

[BobRodes]

Interesting. I've run across it in three different projects, as recently as 3 years ago. Just to see, I tried googling the exact error message, and find that I wasn't alone. This link is an example:

http://www.xtremevbtalk.com/showthread.php?t=248653

and also gives some other useful information.

 

[strongm]

Ah - but mainly because I've never tried to get the PDW to do something it wasn't designed to do. I've always packaged on the oldest OS I expect to run the software on.

 

[HughLerwill]

...and I suspect used the files contained in the original redist folder installed with VB6, or similar ones of Win2k vintage or earlier.

 

[dilettante]

That's exactly why the PDW's redist folder exists.

You're expected to put redistributable dependencies in there which are the oldest ones your program requires. In general the files here should be ones that the installation of the VB6 compiler and tools put here, updated along the way by installing VB6 service packs. You might add other files here to handle special cases.

The idea is that PDW picks up your project's dependencies from this redist folder. Then when you run the setup on a target system you'll only install system files if those of the target are simply too old to allow your program to run at all.

See Best practices for deploying Visual Basic 6.0 applications and of course Get Started with the Package and Deployment Wizard (PDW).

In general there is no need to develop and package on an old OS even when targeting old OSs. Of course you're supposed to know enough to override packaging of things like msvcrt.dll and individual MDAC components in PDW.

 

[BobRodes]

<oldest ones your program requires

Yes, that's so. The whole thing strikes me as a massive kludge, however. It means that your program deployment isn't easily backwardly compatible with older operating systems than the dev machine. As strongm points out, it wasn't designed to do that, and at the very least that's counterintuitive, given all the Microsoft spin about backward compatibility.

In the end, I guess I'm saying that I'm unwilling to be an apologist for the PDW when there are better solutions available. Nevertheless, the information here is useful in situations when one might be stuck with it.

 

[pmcdaniel]

Thanks for the replies all. Looks like I'll have to test the process which won't be for a while. But at least I have something to to put in my status on possible procedures for deployment.

We were informed Tuesday we may be moving to .net so I may be creating a .net application instead. Hopefully they'll let us know soon but I'd like to re-iterate my appreciation of your advice/discussions.

I will let you know how it goes if I am given permission to proceed.