views:

135

answers:

3

When trying to remove our application in Add/Remove Programs, the following error pops up, and the application fails to uninstall:

Error

'mFileBagIDE.dll' is not a valid short file name.

The curious thing is that you only get this error if the original installation DVD is not in the drive. If the DVD is in the drive, the uninstall works perfectly.

Here's the real kicker: we did not catch this bug until after our application was already widely deployed, and our clients' situations are such that it is likely many of them no longer have their original DVD. This means that the next version's installer (doing a windows installer major upgrade) will fail because it is unable to first remove the previous version.

So, my question is twofold:

  • What did we do to create this problem so we can avoid it in future releases?
  • Is there a way to tell our next windows installer to ignore this error and go ahead and remove the previous version?

Our current installer (the one that is causing problems) was generated using InstallAware. We're likely moving to WiX. But solutions in any platform (InstallAware, WiX, raw MSI tables) are appreciated!

UPDATE: I have the following row in both the InstallExecuteSequence and InstallUISequence tables in my MSI, which may very well be relevant, but I have no idea what the SRCDIREX property is, or where it is being set.

| Action        | Condition    |
|---------------|--------------|
| ResolveSource | NOT SRCDIREX |
A: 

have you tried to copy those files to %WinDir%/system32 folder?

EDIT: Make a setup to copy all the setup MSI package to the disk, and install it from the diskdrive. Remove every files uneeded to uninstaller. Adobe, HP and many other companys are doing that.

CuSS
I haven't. Do you mean before trying to uninstall, copy some files to the system32 folder? Or as part of the new install? I'm not incredibly familiar with windows installer, but is that a typical best practice? Messing manually with the system32 folder sounds a bit draconian to me. :)
Dave
No, that won't work. The MSI is looking for the file at a specific location, and won't search the path tree to look for it.
ewall
i have edited the answer, i hope it helps :)
CuSS
+2  A: 

Probably one of the actions (either standard or custom) that references the original MSI was not conditioned to run on installation only (for example, ResolveSource should be conditioned as "Not INSTALLED"). You might be able to workaround this with a patch (an MSP file) that changes the condition on the relevant action.

On Freund
I think this may be it! I have a ResolveSource action in both InstallExecuteSequence and InstallUISequence. The condition for both is "NOT SRCDIREX." I'm coming up with a total blank on what this property is. How do I check where the value of that property is being set?
Dave
You can open up the MSI with orca and search for SRCDIREX, maybe you'll be able to find something.
On Freund
Yeah, I tried that and no matches except the two from the ResolveSource action. Is there anywhere else that could be?
Dave
The property could be created by a custom action that InstallAware created... I am not familiar with how InstallAware packages the app, so that's just a guess--but it wouldn't be surprising since many of the other MSI-packagers (e.g. InstallShield) do funky custom actions in lieu of some of the built-in properties.
ewall
A: 

I would start by determining which action is causing the error. Here's how I would do that:

  • Install your app from the dvd
  • copy the msi file to some local folder, let's say "c:\temp"
  • Remove the dvd
  • kick off the uninstall like this: "msiexec /x yourapp.msi /L*v c:\temp\uninst.log"

When the error comes up, the uninstall is effectively paused. You can then check the end of the log to see exactly where you are in the sequence. That should help you to debug.

If the answer really is ResolveSource, regular patching may not be an option. Heath Stewart mentions this in his blog - http://blogs.msdn.com/heaths/archive/2007/10/25/resolvesource-requires-source.aspx

"In general, do not schedule ResolveSource. If this runs when installing a patch, for example, the user will have to insert the original media whether they would otherwise need to or not."

If that's the position you find yourself in, you could create a transform that updates the condition on your ResolveSource action, and apply that to the cached copy of the msi file manually. It's a bit of a pain, but I'm pretty sure that would work.

Ed