|
-
Sep 25th, 2021, 05:13 PM
#2
Re: Create VB6 App Installation Package to install on latest Win OS's
No-no Setup requires you to know everything and get it all very close to exactly right. And even then you risk breaking other applications, especially if the user ever uninstalls yours.
It is concentrated evil in all but the most careful expert hands.
While there are newer technologies today, I believe the best one for VB6 programs is still base on Windows Installer technology. For the VB6 OCXs Microsoft even provide merge modules yet. Those have most of the necessary "intelligence" built in.
Of course you still should know which OCXs your program uses, and for 3rd party OCXs (or your own) you may find yourself left to your own devices yet. These should normally always come with a .DEP file describing things like where to install it.
The old PDW can be used safely, but only if it can read an updated VB6DEP.INI, which is a sort of "global .DEP file" that it tries to use when it can't find a specific .DEP file for a library. Updating VB6DEP.INI is your responsibility, and you might need several of them if your program targets downlevel systems like Win9x as well as OSs from Vista onward. That's because conditions changed over time. What to update in there largely comes from reading 20+ years worth of MS KB articles.
But at least the PDW is smart enough about checking for existing copies of things and about unstalling properly - unlike the No-no.
This is part of why Microsoft dropped Standard (home game) Edition when VB6 was released. VB6 is only meant for professional use, much like VC++.
It's also why they moved on to .Net where they could avoid the hazards to the OS they encountered when the great unwashed used VB5. The vast majority of .Netters seldom use anything but ClickOnce deployment which is well sandboxed.
Windows now fairly aggressively protects itself, but it can't do very much about protecting other applications from the No-no or similar legacy scripted setup packages.
Some VB6 applications can also use private assemblies to isolate their dependencies. That doesn't help if you have any ActiveX EXE's, but aside from that it might be safest. Not only does it protect you from No-no Setups running roughshod all over the filesystem and registry, it also makes simple XCopy Deployment possible.
Then your installer only has to unpack the files into a destination and create Start Menu shortcuts and stuff. The downside is that uninstallation via Control Panel isn't supported without extra work. It can still be done, but few bother.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|