This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: files not being removed
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 20, 2007
06:24 PM
files not being removed
Greetings,
I have an installer that dependant on a unlock code will install the files that make up is associated witht he unlock code. However, there is a group of files that are not being removed and I am not sure why that is the case.
They seem to be set up correctly, but I was wondering if anyone has any ideas on what could be causing this. Thanks.
JD
I have an installer that dependant on a unlock code will install the files that make up is associated witht he unlock code. However, there is a group of files that are not being removed and I am not sure why that is the case.
They seem to be set up correctly, but I was wondering if anyone has any ideas on what could be causing this. Thanks.
JD
(13) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 21, 2007
03:08 AM
You will want to generate a verbose uninstallation log for clues.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 21, 2007
05:58 AM
TsungH wrote:
You will want to generate a verbose uninstallation log for clues.
how do you do that?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 23, 2007
05:00 AM
There are two ways. One is to turn on system policy (see http://msdn2.microsoft.com/en-us/library/aa369776.aspx) and enable logging for all Windows Installer packages.
The other is to provide command line parameter, which depends on your release configurations, setup.exe or not. You can find all switches available at Support.
The other is to provide command line parameter, which depends on your release configurations, setup.exe or not. You can find all switches available at Support.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 27, 2007
02:24 PM
TsungH wrote:
There are two ways. One is to turn on system policy (see http://msdn2.microsoft.com/en-us/library/aa369776.aspx) and enable logging for all Windows Installer packages.
The other is to provide command line parameter, which depends on your release configurations, setup.exe or not. You can find all switches available at Support.
I am probably doing this incorrectly, but I followed the steps in the link above and got nothing when I uninstalled the app.
This is the strangest thing I have seen so far with Installshield (and I have to admit I have seen some strange things since I started using this application), I could have 20 files in my application, of those 10 of them are left behind as orphans.
I have gone through the installshield project itself and done some major cleanup, and I am still gettingt he same results.
For the files that are left behind I compare the settings against the ones that are removed when I do a uninstall. The settings are the same, but yet it does not get removed.
In case you can't tell, I am a wee bit frustrated with this, I just want the orphans to go away when I uninstall the app. Just like the rest of the files of that make up the application. 😄
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 27, 2007
02:49 PM
To create an uninstall log, perhaps run a command similar to this:
msiexec /i ProductName.msi REMOVE=ALL /L*v uninstall.log
One possibility is that the files' shared reference counts are greater than zero after uninstallation, meaning the files should stay around...
msiexec /i ProductName.msi REMOVE=ALL /L*v uninstall.log
One possibility is that the files' shared reference counts are greater than zero after uninstallation, meaning the files should stay around...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 27, 2007
04:00 PM
RobertDickau wrote:
To create an uninstall log, perhaps run a command similar to this:
msiexec /i ProductName.msi REMOVE=ALL /L*v uninstall.log
One possibility is that the files' shared reference counts are greater than zero after uninstallation, meaning the files should stay around...
That was what I was thinking, so I changed that setting on the files in question and in the middle of rebuilding the project and seeing if that will solve it.
If that is the case, then why would some of the files be removed and others not? Thanks for the suggestion. I will see what I find out. 🙂
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 28, 2007
08:27 AM
jjb8297 wrote:
That was what I was thinking, so I changed that setting on the files in question and in the middle of rebuilding the project and seeing if that will solve it.
If that is the case, then why would some of the files be removed and others not? Thanks for the suggestion. I will see what I find out. 🙂
The setting I changed on the files is to turn off the shared, changing it from Yes to No and still got the same result. I did run the MSIEXEC command you gave and not seeing anything that signifies an error.
I am still very puzzled by why some files are removed and others are not in the same directory. Getting to the point where I may need to rebuild the installer, but that wouldn't be the road I want to go down at this stage.
I have attached two screen shots, one has the settings for a file that is not removed, with the shared set to No (it use to be Yes, but still did not go away). The second is an exe file that is removed.
😞
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 28, 2007
09:10 AM
In the log file you created during uninstallation, are the un-removed files mentioned at all? Anything about "client still exists" or the like?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 28, 2007
09:20 AM
RobertDickau wrote:
In the log file you created during uninstallation, are the un-removed files mentioned at all? Anything about "client still exists" or the like?
For the CDSDK there is no entries like the one you mentioned above, there is 4 separate entries for it based on the edition that I am installing.
I have 4 editions of my software and they are express, enterprise, professional and one other whose name is escaping me right now.
MSI (s) (30:A0) [08:42:09:596]: Component: CDSDK.dll_Express_Root_1; Installed: Local; Request: Absent; Action: Null
MSI (s) (30:A0) [08:42:09:612]: Component: CDSDK.dll_Professional_Root_2; Installed: Local; Request: Absent; Action: Null
MSI (s) (30:A0) [08:42:09:612]: Component: CDSDK.dll_Enterprise_Root_3; Installed: Local; Request: Absent; Action: Null
MSI (s) (30:A0) [08:42:09:612]: Component: CDSDK.dll_Express_Art_Root_4; Installed: Local; Request: Absent; Action: Null
This is the only time it appears in the log file, there is no mention of not being able to uninstall this file in the log.
I am seeing this entry
MSI (s) (30:A0) [08:42:09:237]: Disallowing uninstallation of component: {55EB89C8-343D-4A52-8CEF-234DE6C4C5A1} since another client exists
and I tried to see if this was in my project and don't see it, and searched the registry to see if it is in there and was not able to find it. So I have no idea what component this is?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 28, 2007
09:35 AM
That GUID might be from a merge module; if you open the built MSI (and not the ISM project file), do you see it? A quick web search suggests it's related to ATL.
Are there perhaps leftover reference counts (from earlier test runs) in the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs?
Are there perhaps leftover reference counts (from earlier test runs) in the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 28, 2007
09:44 AM
RobertDickau wrote:
That GUID might be from a merge module; if you open the built MSI (and not the ISM project file), do you see it? A quick web search suggests it's related to ATL.
Are there perhaps leftover reference counts (from earlier test runs) in the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs?
I looked in the registry key suggested above and found some entries in there, I am removing them and re running the install again. Although, I seem to remember running this on a VPC image and getting the same results. However, I will try it again and see what my result.
Can't be any worse than the last time I ran it. :rolleyes:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 28, 2007
02:16 PM
😄
:cool: Sweet. Finally got this to work, thank you for the registry entries check, I made one other change to my project in regards the shared files. And ran it through a number of tests and hey presto, it cleans up after itself when it is being uninstalled from the machine.
Thanks again for your help.
jjb8297 wrote:
I looked in the registry key suggested above and found some entries in there, I am removing them and re running the install again. Although, I seem to remember running this on a VPC image and getting the same results. However, I will try it again and see what my result.
Can't be any worse than the last time I ran it. :rolleyes:
:cool: Sweet. Finally got this to work, thank you for the registry entries check, I made one other change to my project in regards the shared files. And ran it through a number of tests and hey presto, it cleans up after itself when it is being uninstalled from the machine.
Thanks again for your help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 28, 2007
02:18 PM
Great news---thanks for posting the follow-up.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)