RemoveFile Table/Component issues

[sean_larkin]

I have a basic MSI project in which I want to remove a user created file, i.e. the file is not part of the installation, but rather is created when the application first launches. I want this file to be removed anytime an uninstall or an upgrade is performed. I tried adding a component to the component table manually, but there is always a red exclamation point next to its folder icon. I can't associate the component directly with a file like I would if the file was being installed, so how should I define this component? And what should its destination be?

I then add the filename to the RemoveFile table by associating this filename, "filename.txt", with the component I just defined. For the Directory I put INSTALLDIR and for install mode I put 3. What am I doing wrong?

Thanks,
Sean

[RobertDickau]

Instead of going through the Component table, perhaps use the Setup Design view to create the component inside a feature (or attach that component to an existing feature)? The red exclamation point just means that the component isn't attached to a feature and therefore won't ever be installed.

[sean_larkin]

Thanks Robert, that did it. But really this was just an exercise for me that leads to a bigger challenge. I have a folder that gets created when the application first launches(not at install time) and it is filled with 100's of files with subfolders. I also want to delete these whenever an upgrade or uninstall is performed. Is this possible using the RemoveFile or RemoveFolder actions? I haven't been able to get this to work if i jsut give the RemoveFile table the folder name. Is the only solution for this to write a custom action that deletes the folder and al of its subfolders and files? Is there a function that I can call to accomplish this in an InstallScript?

Thanks,
Sean

[RobertDickau]

There's not a strong built-in solution; records in the RemoveFiles table can remove wildcard lists of files in a single directory and also remove empty directories, assuming you have a Directory property representing each one, but there's no documented way to ensure records are processed in a particular order.

InstallScript does have a DeleteDir function (to be used with care if you specify to delete non-empty directories). The "DeleteDir" help topic has details, cautions, etc.

[sean_larkin]

That's the only solution I could come up with as well. Here's what I wrote in an InstallScript for my custom action.

function DeleteMCRDir(hMSI)
// To Do: Declare local variables.
NUMBER nSize;
STRING strInstallDir, strMCRDir;
begin
nSize = 256;
// To Do: Write script that will be executed when MyFunction is called.
MsiGetProperty(hMSI,"INSTALLDIR",strInstallDir,nSize); // get the directory where the folder is located
strMCRDir = strInstallDir + "MATLABFunctionLibrary_mcr"; // add the name of the folder to the directory
LongPathToQuote(strMCRDir,FALSE);
DeleteDir(strMCRDir, ALLCONTENTS); // delete the folder and all of its contents
end;

I suppose that I could check whether or not the folder exists, but I think the error gets handled internally...so I can be lazy. Do you think a proper place for the custom action is after the RemoveFiles action? I put it there and it works, but I don't really know best practices for this sort of thing and I guess I couldn't be doing something wrong that might cause unknown problems.

[RobertDickau]

Sean,

Assuming it's not an option for a bunch of those files to be included with the installer rather than uncompressed/created at app run time---doing things this way also loses rollback, self-repair, patching, etc., of course---scheduling the action around RemoveFiles with an appropriate condition sounds right.

A complication is that you'll want to run the action in deferred mode, which means that your MsiGetProperty call will need to go through CustomActionData. Please see "Accessing or Setting Windows Installer Properties Through Deferred, Commit, and Rollback Custom Actions" (and search the help and these forums for "CustomActionData") for more information...

Robert