Creating non-healing folders and files on a target system.

[Steve]

Hello; I have two questions that I am hoping to find answers for...
Question 1):
I need to create mulitple folders (and file) on the target system during my installation that will not be self-heal in the event that they are later moved.
The reason that I need to do this is because I have found that my clients often need to move such folders (and files within them) to a server to ensure that they are backed up daily.
The problem is that if I create the folders during the installation, once the client moves the folders to their server, the installer's self healing feature kicks in and restores the missing files and folders.
So I guess what I am really looking to so is create those files and folders during the install, but then have installer forget that they ever existed.

Question 2) I also need to enure that in the event that the client leaves the folders in the default installation location, that during an upgrade or uninstall those folders are not removed. I know how to do this with files, but doing so with folders has me stumped.

Thanks,
Steve

[MichaelNesmith]

1) Do not use advertised shortcuts or file types. This will disable self-healing functionality. Of course, if a user manually initiates a repair, the repair will still occur.

2) Create folders directly using the Win32 API call CreateDirectoryA function in kernel32.dll using the Call DLL Function command. Do this before Apply Install, and Windows Installer will not remove them as they have pre-existed by the time it kicks off.

[mberterm]

I need to create mulitple folders (and file) on the target system during my installation that will not be self-heal in the event that they are later moved.

There is the possibility that auto-repair/self-heal could be triggered manually with an MSI API like MsiReinstallFeature or through the MSI command line parameter </F>.

MsiReinstallFeature - http://msdn.microsoft.com/library/en-us ... eature.asp
MsiExec.exe Command Line Parameters - http://helpnet.installshield.com/Robo/B ... ineMSI.htm

Application Resiliency: Unlock the Hidden Features of Windows Installer - http://msdn.microsoft.com/library/en-us ... ration.asp
See the section entitled, 'Challenge #1: Self-Invoked Resiliency.'

How Does The Self-Repair Feature Work? - http://www.appdeploy.com/faq/detail.asp?id=52


Add to the previous suggestions...

+ define a Component 'registry' key path instead of using a file
... - defining no key path, MSI uses the Components destination as the key--to delete this will then open the possibility for a repair
... - however, key files are also what MSI file replacement rules use for minor upgrades and patches

+ do not use the Component attributes of 'permanent' or 'shared'

+ depending on design, you might need to manually copy files (say from a temp location) to the directories created via API's

+ leave no trace when installing the package - not recommended because it is a package wide approach
Adding and Removing an Application and Leaving No Trace in the registry
http://msdn2.microsoft.com/en-gb/library/aa367519.aspx


The Microsoft articles below go into the background on Components:

Windows Installer Components
http://msdn.microsoft.com/library/en-us ... onents.asp

Organizing Applications into Components
http://msdn.microsoft.com/library/en-us ... frame=true

What happens if the component rules are broken?
http://msdn.microsoft.com/library/en-us ... broken.asp

Components and Features
http://msdn2.microsoft.com/en-us/library/aa368003.aspx

I also need to enure that in the event that the client leaves the folders in the default installation location, that during an upgrade or uninstall those folders are not removed.

Simply by using methods to avoid an auto-repair, the folders will remain after an uninstallation. Which means that you should account for this either by documenting the requirement to have the end-user delete moved folders and unregister files or including code for it.

Unfortunately, installing files and folders outside of MSI, so as to avoid auto-repair, prevents the use of native MSI functionality to install the upgrades. You will then need to handle this yourself.