CODEWITHSUNDEEP
wixinstallationwindows-installer
Snixtor
Snixtor

Reputation: 4297

WiX Installer FileSearch with full file path

I'm creating an MSI using WiX, and that MSI accepts as a user-input property, the path to a file name that the installer logic will be using. I'm trying to validate the property by determining whether that file exists, but with a full file path I can't figure out how to get that to cooperate with the DirectorySearch and FileSearch pattern.

So, say the user runs the MSI like: msiexec /i myinstaller.msi CUSTOMFILE="C:\test\input.txt"

I would then need to run something like:

<Property Id="CUSTOMFILEEXISTS">
  <DirectorySearch 
    Id="LocationConfigDirSearch" 
    Path="[CUSTOMFILE_DIR]" Depth="0">

    <FileSearch Name="[CUSTOMFILE_FILENAME]"></FileSearch>
  </DirectorySearch>
</Property>

But I:

  1. Can't figure out how to split the filename into its parts. Something like Path.GetDirectory([CUSTOMFILE]) and Path.GetFileName([CUSTOMFILE]) would be ideal. or;
  2. Can't figure out how to determine whether the file exists using the full file name as-is. Say for example, a property on DirectorySearch for IgnoreFileName="true", but I know such a property does not exist.

Do I need to go to the extent of writing extension code or a custom action? I'm hoping this is a simple enough requirement that it won't need to go that far.

Upvotes: 3

Views: 2516

Answers (3)

PhilDW
PhilDW

Reputation: 20780

Without running a custom action to search the system explicitly, whatever the language, another choice would be to write code to create your own AppSearch in the running MSI file. The key would adding the file to the Path table in the DrLocator table. You'd do this before AppSearch of course.

I don't think it would be a big deal to say that file must have a fixed name and be located somewhere such as next to the MSI file or in the user's AppDataFolder, then you can do an AppSearch for the specific file based on [SourceDir] or [AppDataFolder]

Is this a silent install? Is there a reason why you can't add a custom dialog to browse to the file?

Upvotes: 0

Christopher Painter
Christopher Painter

Reputation: 55581

The FileSearch element is an abstraction for the Signature table in Windows Installer. The FileName column doesn't support the Formatted data type so you can't put a property in that attribute.

What you might be able to do is standardize on a fixed filename and have the user provide a property with the directory path rather then the file path. Then I think you'd be able to use AppSearch to find a file in that directory without writing a custom action.

Otherwise a custom action to do simple discovery without any state changes isn't the worst thing in the world. Just be careful to not introduce any hosting fragility. ActiveScript (VB/JScript) support in Windows Installer is notoriously fragile. I find C#/DTF managed custom actions acceptable but not everyone does. That leaves C/C++ which can be very solid but harder to code. This is a simple CA so it should be pretty straightforward.

Upvotes: 1

Stein &#197;smul
Stein &#197;smul

Reputation: 42136

Checks that don't make any changes to the target system are actually OK to perform via a custom action VBScript. As long as there are no system changes, there is no need for a rollback feature and a script is actually normally easier to use than complex file searching mechanisms. Just make sure to keep the script simple, and test it well.

A question that comes to mind is what is inside this text file, though, and how it is specified for the install session. Do you just pass it on the command line, or is there a browse dialog to specify the path?

Here is just a simple check file script from a script repository:

Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists("C:\FSO\ScriptLog.txt") Then
    Set objFolder = objFSO.GetFile("C:\FSO\ScriptLog.txt")
Else
    'Wscript.Echo "File does not exist."
End If

Note that I don't think you can call Wscript in a VBScript custom action. You will, however, have access to the MSI file's Session object in immediate mode. Deferred mode access is more difficult as explained here, but that's sort of out of scope for the use you indicate.

Upvotes: 0

Related Questions