Re: [WiX-users] WiX How-To Question

[Orion E. <or...@co...>]

I agree with rob in this scenario, but I'm in a funny mood. Code for 
getting props into a C++ dll may also be useful in scenarios where the 
user wants to do something a bit more useful :-)

code for a visual C++ dll. I would give you some VBScript as it's much 
easier to understand, but Rob has decreed that it is bad, so C/C++ is 
the way to go.

#include <msi.h>
#include <msiquery.h>
#include <stdio.h>

/*imagine there's the standard Dll Entry point function somewhere here, 
VC will autogen it for you. */

/*note that you could use a .def file to manage your exports as well,
but I prefer this as you don't have an extraneous file and it's easier 
to see what is and isn't exported */

#pragma comment(linker, "/EXPORT:WriteInstallDir=_WriteInstallDir@4")
extern "C"
UINT __stdcall WriteInstallDir(MSIHANDLE hInstall)
{
    char buf[MAX_PATH+1]; DWORD buflen = sizeof(buf); //+1 for trailing null
    MsiGetProperty(hInstall,"INSTALLDIR",buf,&buflen);
   
    FILE* outfile = fopen("C:\\INSLINFO.TXT","w");
    fprintf(outfile,"%s",buf);
    fclose(outfile);

    return 0;
}

The WiX code to execute this would be:

<Binary Id="MyCustomDll" src="path/to/dll/MyDll.dll"/>
<CustomAction Id="CaWriteInstallDir" BinaryKey="MyCustomDll" 
DllEntry="WriteInstallDir"/>
<InstallExecuteSequence>
    <Custom Action="CaWriteInstallDir" After="CostFinalize"/>
</InstallExecuteSequence>

Note sequenced after CostFinalize because anything before that and it 
won't have worked out what INSTALLDIR actually is. I'm pretty sure 
Costing in the execute sequence is not a deferred action so this should 
all work. If it is, the procedure's different as deferred actions can't 
just read properties like I did above... RTFM for more if you're not 
familiar with that stuff.

PS: Rob, any chance of MSI 3.0 fixing that? Surely allowing access to 
all properties but just making them readonly would be a viable solution 
instead of having a propsetter CA for every deferred action you want to 
do...

PPS: One of the better things about MSI I've discovered is that it 
catches buffer overruns (which you can easily easily get doing things 
like initializing fixed length buffers and sprintf'ing and other C 
string goodness) in your customactions.
Unlike installshield, which gives you no warnings whatsoever, and will 
just randomly nuke your installations without any prior warning... but 
only once in a blue moon if the overrun happens to hit a critical part 
of installshield... One of my many bad experiences with it to say the least.

Anyway, best of luck.