View Full Version : A few problems IS Professional 6.0

02-05-1998, 01:00 AM
InstallShield Corp. <raquino@installshield.com> wrote in article
> Hi Tim,
> I tried reproducing the floppy problem using 5.1, but couldn't. I tried
> with 16-bit installs on both 95 and win 3.11. I just used template one,
> added enough files so two disks were created, and ran it. When the
> disk dialog was displayed, I tried every combination in order to
> the problem. Every time I hit OK, a warning was displayed. Try this
> project on multiple machines to see if the problem is machine specific.
> Then, try a different project on multiple machines to see if it's a
> with InstallShield.

I'll have our testers try again to see if they can reproduce the problem
and what steps they did to produce it, as well as trying it on different

Still have append logfile bugs.....
> When you have a file group marked as shared, and install over a file that
> isn't marked as shared (i.e. no refcount), then the file's refcount
> 2. That's why your shared files refcounts are being decremented to 1,
> not being removed.

Actually this is not what is happening. Here is what I have, I am
overwriting a previous version of our software. With the newer version I
have added one new file that is shared, self-registered and goes into the
System directory. When I install this normally, no previous version, then
the file is registered properly and the refcount is correct at 1.
Uninstall is perfectly fine.

But on the other hand if I overwrite the previous version then this file
will be registered properly and placed into the system directory, but no
refcount is made therefore when I uninstall the file is not removed or
unregistered. What I had to do as a work around is check to see if the
refcount of this file exists at the end of the install and if not create a
refcount of 1. With this work around the file will be removed and
unregistered. This again is a logfile append bug.

Next is that there are 3 out of 4 files that have changed from not shared
to shared and all 4 installed into the system directory. The previous
install put 3 of these files into the system directory, 1 was shared and
the other 2 not, and the other file into the program directory. When I
install over the previous version the 1 file that was shared is fine, the
refcount does not change because I am overwriting the logfile and the
reference to that file is there. The problem are the remaining files.
Since I am appending to the logfile there must be a reference to the files
that I am trying to install that says that the files are not shared and the
location of them. What happens is that the files are installed, but again
no refcount is created for them. This again is a logfile append bug. It
seems that if a file has changed it's properties and/or location on a newer
version then these changes are not reflected properly in the logfile,
therefore causing problems when it is time to uninstall.

> I was able to reproduce the problem with the product version remaining in
> the registry.
> I think the best workaround would be to have separate uninstall log files
> for each installation (if installed to different locations). Your
> uninstallation could use a custom uninstall to launch the previous
> uninstallation. It would do this in UninstUninitialize. When setting up
> the uninstall command line, it could remove the DisplayName value from
> previous install's uninstall key. This would only be needed if the third
> parameters of DeinstallStart were different for each install. This
> workaround should take care of the shared files and the product version
> issues.

The problem is that we have 3 installs. One is a combined install that
installs two products into one directory. The other 2 installs are the
standalone installs of the two products that the combined install installs.
When installing the combined I check to see it either of the standalone or
a previous copy of the combined install exists. If they do the I prompt
for overwrite and install into that same directory. The main reason for
this is that all the products use the exact registry entries and therefore
installing into different directories and creating different logfiles will
cause problems during uninstall. If one is uninstalled then all registry
entries will be removed, which will cause the other product to fail on
execution. I also noticed that if I do not append to the logfile and I
uninstall individually that the last uninstall will receive the Details
button, because it is complaining about files and/or registry entries that
can not be removed because they have already been removed by one on the
previous uninstalls. Again this does not look good to the customer. Again
this means that the append feature needs so work to account for these

> --
> Rich
> InstallShield Software Corp.
> P.S. Our website, http://www.installshield.com/, covers a wide range of
> resources for your installation development. Read technical whitepapers,
> view documentation or search the Knowledge Base to get support
> 24 hours a day, 7 days a week.
> Tim Mayert wrote in message <01bd3182$0d932ae0$4e01a8c0@timm133>...
> >Hello IS, I have a few problems that I would like to know if there are
> >fixes or work arounds for.
> >
> >One is a problem that our testers have found that concerns installing
> >disks, on a Windows 3.1 - 3.11 machine. What they did was start the
> >install and then when it asked for disk 2 they hit the Browse button and
> >then pressed cancel and then pressed OK. The transfer started again and
> >failed with a File Transfer error. They tried it again and simply did
> >the proper way and it installed fine. It seemed every time they pressed
> >the Browse button and then canceled that they would get a failure. Can
> >check into this problem to verify if it exists.
> >
> >Another problem I have is appending a previous uninstall log file. Some
> >my installs have separated into other product installs that are now
> >common files to be placed into the system directory. These files are
> >to be considered shared files among our apps and therefore I mark them
> >shared. This is fine for the new versions, but my problem is our
> >version. What I do is register all my apps into the registry so that I
> >find them on a newer install. I then search for the entries in the
> >registry so I can find the location of the app, the folder name, the
> >and location of the uninstall log file, and the version number. I then
> >prompt the user if they want to overwrite this app or create a new
> >directory. Since the app self-registers and the entries are common
> >different versions I simply keep track of the location and name of the
> >uninstall log file so that I will append to it even if the user decides
> >to overwrite the previous version, this way when they uninstall all
> >directories of this app will be uninstalled. The problem comes when the
> >shared files are installed, the previous install placed the files in the
> >system directory without having to set a shared flag. Then the new
> >overwrites those same files, but this time sets the shared flag. This
> >OK as it was suppose to set the shared flag to 1, but then when I
> >I notice that the file is gone but the shared reference number did not
> >change and was not removed. This then causes two problems, one is that
> >uninstall was not clean by leaving that reference and the other one is
> >on the next install the shared reference count will be incremented to 2
> >therefore the file will never be removed.
> >
> >The previous problem also caused another problem with appending the
> >uninstall log file. Since the product name was the same, but the
> >number was different, another entry in the registry was made with:
> >basically this is what the registry entry look like.
> >First version
> >HKEY_LOCAL_MACHINE\Software\Test Company
> > HKEY_LOCAL_MACHINE\Software\Test Company\Test Product
> > 1.0
> >
> >Then the second version is installed and I append to the first versions
> >uninstall log file, both overwrite previous and not overwrite, and this
> >the result:
> >HKEY_LOCAL_MACHINE\Software\Test Company
> > HKEY_LOCAL_MACHINE\Software\Test Company\Test Product
> > 1.0
> > 2.0
> >
> >Now this is fine again, because nothing has been removed YET....
> >Now I run the uninstall and when the uninstall is complete I says that
> >uninstall was successful, but when I check the registry this was not
> >removed:
> >HKEY_LOCAL_MACHINE\Software\Test Company
> > HKEY_LOCAL_MACHINE\Software\Test Company\Test Product
> > 2.0
> >
> >It looks like the
> >registers the information in the registry properly, but does not add
> >(append) it to the uninstall log file to be removed on uninstall. It
> >that appending to the log file still needs some work.
> >
> >If you have fixed any of these in 5.1 let me know, as I will be
receiving a
> >copy at the end of this month (I hope as it is to be the International
> >version), otherwise you will have to look into them. Also if you have
> >viable work arounds that my help I would appreciate it.
> >
> >Thanks,
> >
> >Tim Mayert
> >SMART Technologies Inc. Phone: (403) 228-8552
> >Suite 600, 1177 - 11th Ave SW Fax: (403) 245-0366
> >Calgary, AB T2R 1K9 mailto:TimMayert@smarttech.com
> >visit our website at: http://www.smarttech.com

12-06-2001, 12:08 PM
1. I place a .ini file in the system directory. When the program is uninstalled, the .ini file remains in the system directory...however it is a zero byte empty file. I used WriteProfString in the script to edit the .ini file.

2. The start menu shortcut isn't removed on uninstall.

3. When I use package for the web, the srcdir is changed to the temporary directory where the files are extracted. How can I make the srcdir the directory where the package for the web executable resides?

Can anybody help with this? Please?

Thanks in advance,