Help on Installation/Setup removing previous versions 2

[dbleyl]

Hi,

I want to create a setup that detects previous versions and removes them before installing the new version.

The previous versions used the standard setup. The program(s) appears in the Add/Remove. I want the new setup to run silently as possible, and wipeout all these entries in the Add/Remove.

Because we send updates often, users are in the habit of running setup all the time, so they have many copies.

How do you get to the information that non-vb programs store in

HLM\Software\Microsoft\Windows\CurrentVersions\Uninstall

is there a hack to run st6unst.exe from the command line like you can uninst.exe and isuninst.exe?

Even if we use Wise or InstallShield, we still have to address the mulitiple copies that already exist.

I haven't ruled out writing a custom C++ utility or shell script that does the dirty work like regsvr32 -u and the like.

Any suggestions would be helpful.

 

[dbleyl]

I stand corrected. You can call st6unst from the command line.

VB does add info into the HLM\...\Uninstall key, just under
ST6UNST #X\...
with UninstallString C:\WINNT\st6unst.exe -n "C:\Program Files\YourProgram\ST6UNST.LOG"

Has anyone written something to parse the st6unst.log file, and maybe check CurrentVersion\SharedDlls\ # of references?

 

[JohnYingling]

You need to transition to Visual Studio Installer which uses the Windows Installer. When you install a new version where a previous version exists, it will first start up a Remove/Repair for the existing version, the same as when you pop VS install CD into the CD reader now. The problem is that the Windows Installer is not present on Win '95 or Win '98 first edition without a download and installation. It is part of the OS for Win '98 2nd edition and above.
You must use "Do not remove" for "legacy" DLLs that are shared. Win '95 and non-Windows Installer installations must disappear before this problem is resolved.

http://WWW.VBCompare.Com

 

[dbleyl]

Thanks, I am looking into the windows installer. Right now, we have to support 95 and 98. I'm worried about having users install a new service pack on their machine, given that it's hard to uninstall the installer, and most of these machines are very antiquated laptops.

What do you use to develop your Windows Installer packages? I've noticed that Wise & InstallShield have WI editions.

Although I've read the white papers & other stuff, I can't find the installer on our visual studio cds. I'm running SP 5. Is it the new Platform SDK?

 

[JohnYingling]

I use both PDW of VB6 and the Visuall Studio Installer. VSI is nice. You use the VisualInterDev Environment to create your installer project. VSI creates the Windows Installer Stuff.

http://WWW.VBCompare.Com

 

[dbleyl]

Cool. I'm trying it out--I think I found where everything is. Do you just add the executable and dependencies to a self-extracting setup Project, compile, and the rest is history?

PDW->I've got my silent mode set-up working complete with uninstall of old version. I can't get st6unst.exe to run in silent mode, although it seems to take \s from the command line. For now, I will prompt the user before removing the old version. If they choose not to, I'll just cancel the setup.

Your advice has been very helpful. Thanks.

 

[dbleyl]

OK--here's the silent uninstall commandline.

C:\Winnt\st6unst.exe -n &quot;C:\Program Files\MyProgram\st6unst.log&quot; /s <Path&FileNameForUninstallLog>

I should have examined the Setup1.vbp better.

 

[JohnYingling]

You tell VSI where your project is and that it is VB. It requires that you have already done a compile. Apparently there are MSMs (whatever) in VB libraries for various dependencies. Start / Programs / Visual Studio 6.0 / Visual Studio 6.0 Enterpise Tools / Visual Studio Installer and Visual Studio help. Watch the third party controls. If you do not mark them as &quot;legacy do not remove&quot;, the uninstaller will take them off your machine when you test an uninstall.

http://WWW.VBCompare.Com

 

[MikeCox]

I've been searching for a solution to the same problem dbleyl was having, and it looks like I've found it here. However, I'm having problems importing my VB project into InterDev to take advantage of the Windows installer, as .vbp isn't one of the filters in the InterDev dialog. I don't know much about InterDev, and the Visual Studio Installer is missing from my Start Menu. What is the actual name of the VSI executable so I can run a search? I may be able to figure it out from there. Thanks!

 

[JohnYingling]

You may have to download and install Visual Studio Installer if you can't do the following in InterDev.
Click on New Project. New Tab, left pane Visual Studio, Visual Studio Installer Projects, right pane Visual Basic Installer, then browse in the wizard, and it has files of type *.VBP and *.*. I have a .MAK because it was originally VB3.
Head on down to

http://msdn.microsoft.com/vstudio/downloads/updates.asp

to check it out.

http://WWW.VBCompare.Com

 

[MikeCox]

Excellent! That was it, thanks a million.

 

[MikeCox]

Well, I FINALLY downloaded Visual Studio Installer 1.1 and imported my VB project fine, but I'm still not having any success. I made a small change, recompiled, ran VSI again, ran the resulting Setup, but when I run the project it's the old application, and I don't know where the new one went. I tried deleting the VBInstaller1 folder it made and rebuilding everything, but it doesn't seem to detect or replace the old application unless I run the origional Setup. Am I doing this wrong, or is there no way to allow users to automatically upgrade? I need my application to detect an upgrade, let the user click the Yes button, launch the installation program, and unload my application. Then the next time the user clicks on the existing shortcut (or the one VSI makes), the newest .exe is launched, and the older one has been uninstalled. Sounds simple, but this has been one of my biggest headaches, particularly since most users don't feel comfortable using the control panel to get rid of the old program. With such technology as COM, ASP, and DirectX, it stands to reason such a trivial task as overwriting old files during an installation would be available somewhere. Thanks a million for any feedback.

 

[MikeCox]

I believe I've found my answer on Microsoft's website, which states:

You must be aware of an important Microsoft® Windows® installer consideration whenever you run a changed version of an installer package (.msi) file. This is that the installer, after successfully installing an application, maintains a cached version of the original .msi file on the target machine. This cached copy of the .msi file is an important safeguard for your user, because it maintains the information necessary for any future installation repairs.

However, this cached version of the .msi file can interfere with testing and debugging, because the Windows installer will always run the cached .msi file, unless it is uninstalled. That means, you could make changes to a Microsoft® Visual Studio® Installer project (.wip file), build them into a new version of your installer package (.msi) file, and then run the installer package — and the new installation will not include any of your changes. That's because the Windows installer would run the original, cached version of the .msi file not the newer version you have just built.

It looks like users are going to have to get used to uninstalling/reinstalling, unless someone knows an API function to invoke the Add/Remove Programs in the control panel, or any other way to silently uninstall an old program and install a new one.

 

[JohnYingling]

I missed something. When I do a second install it automatically runs the cached version to REPAIR or REMOVE. I then run my new install again after the REMOVE.

http://WWW.VBCompare.Com

 

[dbleyl]

Hi Mike,

I wrote a wrapper for the standard VB setup that works great for what we needed.

The program uses WIN32 API functions:
GetFileVersionInfoSize()
GetFileVersionInfo()
VerQueryVal()
FindFirstFile()

It looks for the program on the user's machine. If the program's there, it checks the version against the CD. If the versions are the same, it just starts the program. If the version on the hd is older, it spawns st6unst.exe, and removes the old version in unattended mode.

Once the version is removed, or if the program wasn't there to begin with, the installer spawns setup.exe and installs the new version in unattened mode.

Once uninstall/install has been handled, the installer executes the main program and terminates itself.

When the user puts the CD in, they don't have to do anything, the installer either starts the program, installs and starts it, or uninstalls the old, installs the new, and runs it.

Calling setup.exe and st6unst.exe gets tricky, you just have to pass the right log files and switches when you call it.

 

[MikeCox]

I see...it looks like the wrapper is a separate exe that handles only upgrade stuff, or possibly in sub main. It seemed that I would need to shell the old .msi to let the user select &quot;remove&quot;, then shell the new .msi once (s)he's completed the removal. But it sounds like I can shell st6unst.exe, I'll have to play with that a bit. The tricky thing is I maintain all updates on a network drive, and without st6unst.exe, I was looking at maintaining two .msi files, one for removal and one containing the upgrade (then what happens if two upgrades become available before some user upgrades once?).

I've been using the shell statement to call the PDW setup.exe without any problems (except previous installation detection), could you possibly elaborate on passing the right log files and switches? I'm somewhat of a VB newbee (self taught so I may have some blanks to fill in), and I haven't seen that before. Thanks a TON!

 

[MikeCox]

Ok, I tried the shell statement on st6unst.exe and I'm told that the application removal device can only be run from the program manager or control panel. This is the tricky part you were talking about? I seem to get the same results using WinExec API or invoking from a batch file.

 

[dbleyl]

Hey Mike,

OK, here's the deal:

When you call st6unst.exe, you pass 2 switches and two log files:
C:\Winnt\st6unst.exe -n &quot;C:\Program Files\MyProgram\st6unst.log&quot; /s <Path&FileNameForYourUninstallLog>

VB makes st6unst.log for you in the application's directory. This is the first log.

Then you pass /s to tell it unattended mode, followed by a log file that you specify. This is really cool, because if you need to do support, you have a file to examine.

I wrote my program in C++ using exel & spawnl. That way, it doesn't need the VB runtime to do it's thing.