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: Error uninstalling IIS web site with dynamic port
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
‎Jan 15, 2010
02:54 PM
Error uninstalling IIS web site with dynamic port
Howdy,
InstallShield 2010 Professional, Basic MSI project
I created a dialog to dynamically set the port of the IIS web site the installer creates according to:
Using Windows Installer Properties to Dynamically Modify IIS Settings
Unfortunately, upon uninstall, the Web Site isn't actually deleted from IIS even though the uninstall sequence appears to finish normally. Does the user specifically need to set the port to uninstall from during uninstall, or? Any ideas?
Thanks,
Frank
InstallShield 2010 Professional, Basic MSI project
I created a dialog to dynamically set the port of the IIS web site the installer creates according to:
Using Windows Installer Properties to Dynamically Modify IIS Settings
Unfortunately, upon uninstall, the Web Site isn't actually deleted from IIS even though the uninstall sequence appears to finish normally. Does the user specifically need to set the port to uninstall from during uninstall, or? Any ideas?
Thanks,
Frank
(10) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 15, 2010
03:53 PM
Is the property that contains the port number during installation set to the same port number during uninstall? If not, the runtime won't be able to determine the correct website to remove.
You can create a log of the uninstall if needed to check on the value of the property containing the port value using a command line similar to the following:
msiexec.exe /X {ProductCode} /l*v C:\PathToLog\Uninstall.log
You can create a log of the uninstall if needed to check on the value of the property containing the port value using a command line similar to the following:
msiexec.exe /X {ProductCode} /l*v C:\PathToLog\Uninstall.log
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 15, 2010
04:23 PM
Hi Josh,
Thanks for getting back to me so quickly...
Generating the log as you specified, the property I set the TCP Port Number to, HTTPPORT, is set to 0 and never corrected to be the right value. Property(s): HTTPPORT = 0
Is there a way, during installation when the user sets the value of HTTPPORT, that I can set a value somewhere as to the uninstall value of HTTPPORT? Or, is there a way for me, during uninstall, to search IIS for the name of the Web Site I want to uninstall, or some other identifying characteristic, and find out the port from there?
Cheers,
Frank
Thanks for getting back to me so quickly...
Generating the log as you specified, the property I set the TCP Port Number to, HTTPPORT, is set to 0 and never corrected to be the right value. Property(s): HTTPPORT = 0
Is there a way, during installation when the user sets the value of HTTPPORT, that I can set a value somewhere as to the uninstall value of HTTPPORT? Or, is there a way for me, during uninstall, to search IIS for the name of the Web Site I want to uninstall, or some other identifying characteristic, and find out the port from there?
Cheers,
Frank
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 15, 2010
05:25 PM
A relatively simple solution would be to store this property value in a registry entry in your project that references the property ([HTTPPORT]). Then, create a system search which looks for this registry entry and store the search result in HTTPPORT. On first time installs, this entry likely won't exist and the system search won't change the property value, but on maintenance/uninstall, the system search should find the registry entry and populate the property with the original value.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 11, 2010
06:18 PM
Hi Josh,
I'm running into the same problem: the websites are not deleted from IIS though I set them to do so from the IDE (using IS 2010).
I tried your method, creating two registry entries for the two ports I create during installation and setting up a system search. Unfortunately, even then the websites remain after a Remove.
I'm running into the same problem: the websites are not deleted from IIS though I set them to do so from the IDE (using IS 2010).
I tried your method, creating two registry entries for the two ports I create during installation and setting up a system search. Unfortunately, even then the websites remain after a Remove.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 11, 2010
06:43 PM
One other thing: the virtual directories remain in IIS, in name, at least--no contents within. (When selecting one, "the system cannot find the path specified" obtains.) Not sure if that is the reason for this, but this is quite frustrating, as I need those websites deleted when a user removes the application.
Thanks for any advice...
Thanks for any advice...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 18, 2010
01:45 PM
Can you attach a verbose log of the uninstall of your project that reproduces this behavior?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 22, 2010
02:35 PM
Assuming that one or both of the following components contain the website(s) in your project, this would be the reason they are not being removed:
Notice that each of these components has an action state of Null, meaning no action is being taken and these components will not be removed at uninstall. Earlier in the log the following information is provided:
These lines indicate that something on the machine is causing MSI to believe that the components are shared and something besides the current installation still needs them. These components may or may not be the MASWebServices_Website and Application_Website components mentioned in the log (the MSI package would be needed to verify which GUIDs map to which components). Most of the common causes of this behavior are found in the following article:
Removing Stranded Files
The most common cause of this behavior is an invalid share count for the keyfile of a component. This can be caused by the share count getting out of sync on a development or test machine, or by installing the same keyfile in two different components with the same MSI package (which is a violation of component rules).
MSI (s) (0C:04) [18:20:57:510]: Component: MASWebServices_Website; Installed: Local; Request: Absent; Action: Null
MSI (s) (0C:04) [18:20:57:510]: Component: Application_Website; Installed: Local; Request: Absent; Action: Null
Notice that each of these components has an action state of Null, meaning no action is being taken and these components will not be removed at uninstall. Earlier in the log the following information is provided:
MSI (s) (0C:04) [18:20:57:380]: Disallowing uninstallation of component: {EC8F83A8-9006-400A-8B95-946BCF167CED} since another client exists
MSI (s) (0C:04) [18:20:57:380]: Disallowing uninstallation of component: {B6B66950-B9B3-4AF0-8208-5A42B9C23F47} since another client exists
MSI (s) (0C:04) [18:20:57:470]: Disallowing uninstallation of component: {2691E28E-A31D-4C42-BDDA-3EF7B04D90F9} since another client exists
MSI (s) (0C:04) [18:20:57:470]: Disallowing uninstallation of component: {F098AF86-F807-4C32-AA66-3F8CCCCD3B30} since another client exists
MSI (s) (0C:04) [18:20:57:480]: Disallowing uninstallation of component: {223FD840-5D3F-4F63-B064-B559422E2CB5} since another client exists
These lines indicate that something on the machine is causing MSI to believe that the components are shared and something besides the current installation still needs them. These components may or may not be the MASWebServices_Website and Application_Website components mentioned in the log (the MSI package would be needed to verify which GUIDs map to which components). Most of the common causes of this behavior are found in the following article:
Removing Stranded Files
The most common cause of this behavior is an invalid share count for the keyfile of a component. This can be caused by the share count getting out of sync on a development or test machine, or by installing the same keyfile in two different components with the same MSI package (which is a violation of component rules).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 22, 2010
04:01 PM
Hi Josh,
I found my problem. Thanks for pointing me in the right direction!
I found my problem. Thanks for pointing me in the right direction!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 22, 2010
04:04 PM
Incidentally, for any others that run into this, the problem was that the websites' file components had their destination set to [INSTALLDIR]. Once I changed this to [INSTALLDIR]\, the websites are now deleted on uninstall.
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)