views:

342

answers:

1

I am having troubles uninstalling a shared win32 SxS assembly using Wix3 on WinXP. My wix file looks pretty much like the one described in http://n2.nabble.com/Tutorial-How-to-install-files-into-WinSxS-td841475.html.

The problem is, if a module from the assembly is in use, the uninstaller completes with a success errorcode but leaves the assembly in a broken state: the manifest and security catalogue have been deleted, but the assembly directory still exists with my dlls in it. The DLLs survive reboots, so are not marked for deletion in any way. There are no obvious errors in the MSI log file.

If I try re-installing the package, it skips installation of the assembly. The components are no longer registered, so I can't get Installer to try uninstalling again. The following is shown in the msi log on subsequent installs:

MSI (c) (98:44) [11:46:56:263]: skipping installation of assembly component: {26A273E7-7F9A-4F77-9FA8-5E413A155BEC} since the assembly already exists

I can't find a way of bringing the SxS back into a good state short of manually deleting my assembly's directory, which at this point is no longer being protected by XP System Restore.

While my actual installer is much more complicated, I have been able to reproduce this with a very basic installer that has a single feature containing a single component. That component contains a dll, a manifest and a security catalogue. The dlls <File> element has KeyPath, Assembly and AssemblyManifest attributes set. Once installed, I can simulate a process loading the assembly by opening the DLL in MSVS.

Is there an extra action I should be invoking on uninstall to detect and prevent this situation? Alternatively, is there a way of forcing the install operation to be performed even though the DLLs already exist in WinSXS?

Somewhat related, I also have a problem if I try to upgrade the package that installed the assembly if the assembly is not changing. The installer decides that it does not need to reinstall the assembly (since it has not changed), but then when the SxsUninstallCA runs, it goes and removes the assembly. From Installer's point of view, the component is still installed, but the files are gone.

+1  A: 

I'm working on something which I believe I'll run into this same problem.

My assumption at this point is that I’d have to solve this with a little mojo from the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations regkey, and a possibly bit of file permission smacking (if the files were still locked).

Which of course, requires a reboot.

Of course, in your installer, you could check for the presence of the keys and block on install until they're gone. (ie "you need to reboot").

Garrett Serack
The problem is, there's no reliable way of knowing where Fusion is going to put the assembly, so you don't actually know which files to delete (the sxs name changes between XP and Vista for example).You're really not meant to delete files from WinSxS. That way lies madness.I'm using registry keys as a work-around, but this still doesn't change the fact that some malevolent, non-admin user can hold a handle on one of the files from the assembly. When your uninstaller comes through, you barf your Sxs directory.
Martin
I'm pretty sure that the final file placement is deterministic -although, you are correct it's different between XP and Vista+. I know that you're not supposed to delete files from WinSXS, but when the file should've been deleted and wasn't, I say all bets are off. Rob Mensching (the Wix Guy) and I have talked about this and a couple of other issues in some detail, and he's awaiting my solution. :D I'm about 2 or 3 months away from having to solve this myself, but I can go talk with the Fusion maintainers and see what they say.
Garrett Serack