Did you use dark to reverse engineer the previous MSI?
Also, if you are iterating through a directory during the install, you'd
have to schedule this custom action to run deferred. Otherwise, the files
won't be present at the time it runs. I use the following command to pass a
directory to a executable [#CACLS_EXE] where the #--- is the id of the file
which is not in the binary table, it's actually installed. You'd have to
reference wixca as a binary in order to call it. Replace DATADIRECTORY with
your directory property. Then troubleshoot by running with l*v logging
turned on.It's nice to use this QuietExec custom action because the cmd
window won't pop up during the install, too.
<CustomAction Id="SetDataPerms" Property="FilePerms"
Value=""[#CACLS_EXE]" "[DATADIRECTORY]" /t /e /g
IIS_WPG:F" />
<CustomAction Id="FilePerms" BinaryKey="wixca" DllEntry="CAQuietExec"
Return="check" Execute="deferred" />
Dana
On 10/19/07, Jason Rivers <[EMAIL PROTECTED]> wrote:
>
> Hi Dana,
>
> The custom Action i'm calling, actually gets a list of files with an
> extension of ".DIN" & ".DSE" from the directory where our product has been
> installed to. These define the Keyboard for our application, and a session
> file, the user can change these during the install, this is why it is in a
> custom action and not through the .MSI.
> but because it get's the the list of files from where the installer has
> just installed the files to, it does need to have the INSTALLDIR parsed to
> it.
>
> I'm reverse engineering an InstallShield installer because our company
> wishes to move away from that and have our overnight build machine
> automatically build the installers, so the WiX system is great for that, if
> I can get this working anyway.
>
> the main issue is I'm reverse engineering something that was thrown
> together very quickly with limited time.
>
> anyway, if the command I'm using is correct to parse the information then
> I will try and look elsewhere for the issue, it's just this does work on the
> old (installshield) installer using an MSI.
>
> Jason.
>
> On 10/19/07, Dana Gutride <[EMAIL PROTECTED]> wrote:
> >
> > What does the msi log say is happening here? That is usually the best
> > way to troubleshoot custom action errors. The other trick I'll use is pop
> > up a message box from my custom action code and then attach to it with the
> > debugger. As a rule, any custom actions that modify the target system
> > should be deferred and you won't have access to msi properties (use
> > CustomActionData from a dll).
> >
> > One question for you, though... wouldn't it be better to utilize the
> > MSI registry table for creating registry keys? It is not only transactional
> > (your keys are removed if the install fails), but they are removed on
> > uninstall and you can include properties and all kinds of other good stuff
> > in them.
> >
> > Dana
> >
> > On 10/19/07, Jason Rivers < [EMAIL PROTECTED]> wrote:
> >
> > > Hi all.
> > >
> > > I'm having some trouble with parsing information to a custom action.
> > >
> > > I have the command:
> > >
> > > <CustomAction Id="InstallUser" Impersonate="yes" Return="ignore"
> > > Execute="oncePerProcess" BinaryKey=" instexe.exe" ExeCommand="0
> > > /InstallUser [INSTALLDIR] [ALLUSERS]" />
> > >
> > >
> > > and the lines
> > >
> > >
> > > <InstallExecuteSequence>
> > > <Custom Action="InstallUser" After="InstallFiles">NOT
> > > Installed</Custom>
> > > </InstallExecuteSequence>
> > >
> > >
> > > I don't know about the "[ALLUSERS]" but I know it is not parsing the
> > > "[INSTALLDIR]" parameter to the EXE, this EXE sets up all the windows
> > > registry settings for the application we write.
> > >
> > > if someone could help with where I'm going wrong here and give me some
> > > advice on how to parse the INSTALL Directory information, and the Users
> > > home
> > > / All Users Home folders to an EXE or DLL it would be very appreciated.
> > >
> > > Thanks in advanced.
> > >
> > > Jason.
> > >
> > >
> > > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc.
> > > Still grepping through log files to find problems? Stop.
> > > Now Search log events and configuration files using AJAX and a
> > > browser.
> > > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > > _______________________________________________
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
