Windows Develop Bookmark and Share   
 index > ClickOnce and Setup & Deployment Projects > Uninstall custom action -- condition is false -- why?
 

Uninstall custom action -- condition is false -- why?

I'm having a problem uninstalling my web application on a 2008 Server. The custom action that Visual Studio 2008 includes for me (it's an override of Uninstall in a class derived from Installer in one of the project EXEs) is failing to run during uninstall. I configured automatic logging under HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer with values Debug=3 and Logging="vicewarmup".

The log file gives the lines:

MSI (s) (34:C8) [17:41:30:539]: Skipping action: _BFA6F18E_F5B2_41FB_8498_95DD8690AA04.uninstall.SetProperty (condition is false)
MSI (s) (34:C8) [17:41:30:539]: Skipping action: _BFA6F18E_F5B2_41FB_8498_95DD8690AA04.uninstall (condition is false)

Opening up the .MSI file, I can see that the condition in the InstallExecuteSequence table is "$C__43EDDEADFB1AFE0E6A23EF488BD6BF83=2", which should evaluate to true for an uninstall of said component. During install, "$C__43EDDEADFB1AFE0E6A23EF488BD6BF83>2" evaluates to true successfully.

Doing some web exploring, I found a site that said that the most common cause of this condition evaluating false is due to link resolution errors. Now, bear in mind the same executable file contains the correctly functioning install custom action, so it seems highly unlikely that there is a problem here, but I checked anyway, and, sure enough, LINKINFO.DLL was implicated by DEPENDS.EXE, as well as IEFRAME.DLL and SHLWAPI.DLL.

LINKINFO was easy enough to resolve by installing the "Desktop Experience" feature. The others, however... well, one blog I found said that DEPENDS would always misresolve those and to ignore it. I do note that the function names that allegedly cannot be resolved are always of the form #<number>, and, well, as ordinals, those do exist; and, further, DEPENDS shows this problem during linkback -- wherethese DLLs have been linked back to themselves through other DLLs, so I tend to trust that the blogger's comments are correct, and that this isn't really an issue but a problem with DEPENDS.EXE (and/or having DLLs eventually link back to themselves).

Anyway, with LINKINFO added, the custom action is still failing to run.

How can I find out the precise reason that the conditionevaluates tofalse?

Thanks,

=-John-=

John Cullison  Monday, September 14, 2009 7:12 PM
This is nothing to do with depends. It's just saying that condition is false, and the condition $C__43EDDEADFB1AFE0E6A23EF488BD6BF83=2 basically means "this component is being made absent", where the component is the Windows Installer wrapper for the item, probably a file. If, for example, you'd marked the file as Permanent it wil never be uninstalled, and the custom action would therefore not be called.
Phil Wilson
PhilWilson  Monday, September 14, 2009 9:50 PM
Thanks Phil,but this didn't help. I checked all the files and outputs in the setup project, and none is marked Permanent. Are there any other possibilities?

So, the question I asked still stands... how can I find out why the condition is false? This is a standard Visual Studio 2008-created install project. I haven't added any DLLs or vbscript custom actions of my own; I haven't even opened the MSI with Orca to diddle with it at all. I'm just following the .NET way, but something's not happy, and the log isn't revealing it.
John Cullison  Wednesday, September 16, 2009 9:06 PM
That permanent file issue isn't just whether any of the files are currently marked permanent. It's not really a project setting - it's a setting for that component, and if it was ever installed with Permanent=True it will be permanent always.
It's also possible that setting SharedLegacyFile in the setup will affect whether the file/component ever gets uninstalled.
Run this script. It lists all MSI components on the system into a text file. If you open your MSI file with Orca and get the guid for that component from the Component table and then searh for that component, see if there is more than one client product using it. It also might help to post the entire log here, or somewhere all of it can be seen.
Option Explicit
Public installer, fullmsg, comp, a, prod, fso, pname, ploc, pid, psorce

Set fso = CreateObject("Scripting.FileSystemObject")
Set a = fso.CreateTextFile("comps.txt", True)

' Connect to Windows Installer object
Set installer = CreateObject("WindowsInstaller.Installer")
a.writeline ("MSI Components")
on error resume next
For Each comp In installer.components
   a.writeline (comp & " is used by the product:")
   for each prod in Installer.ComponentClients (comp) 
      pid = installer.componentpath (prod, comp) 
      pname = installer.productinfo (prod, "InstalledProductName")
      a.Writeline ("     " & pname & " " & prod & "and is installed at " & pid)
   Next
Next



Phil Wilson
PhilWilson  Wednesday, September 16, 2009 9:42 PM
How do I run that script?
John Cullison  Friday, September 18, 2009 10:23 PM

You can use google to search for other answers

Custom Search

More Threads

• Manifest error - help
• How to execute *.cmd file automatically after the completion of Setup
• Update dialog
• COM depoyment in ClickOnce
• Minimise Command Line Application
• Retrieving OS information during install (System.Configuration.Install.Installer)
• Problem running clickonce app in vista
• Migrating from JApplet to WHAT ?
• System.Deployment.Application without ClickOnce
• S&D project: build failed on WinForms app converted from 2.0 to 3.5