Change in how QtCmdLineAction works?

Jan 26, 2016 at 9:43 AM
Edited Jan 26, 2016 at 12:56 PM
Hi,

I previously used to elevate a batch file using the following code:
 project.AddAction(new QtCmdLineAction(@"[INSTALLDIR]hide.cmd", "", Return.check, When.After, Step.InstallFiles, Condition.NOT_Installed)
                    {
                        Impersonate = false,
                        Execute = Execute.deferred,
                        Attributes = new Dictionary<string, string>()
                    {
                        {"Property", "Action2_QtCmdLine__INSTALLDIR_hide.cmd"}  // This is EXTREMELY important. This property makes it point to itself. If ActionXX_... is wrong, the MSI will fail.
                    }
This worked fine until I upgraded either Wix Toolset or WixSharp (not sure which). Now I get the following error when I try to generate a package:
error CNDL0022 : The CustomAction/@Property attribute cannot coexist with a previously specified attribute on this element. The CustomAction element may only have one of the following source attributes specified at a time: BinaryKey, Directory, FileKey, Property, or Script.
Hide.cmd simply runs attrib.exe /s /h . (from the targetdir), effectively hiding the directory and setting the [system] attribue on it, a requirement by our developers.

Like the comment in the code states, without that attribute the custom action will fail.

Any suggestions on how to resolve this?

Thanks,
Daniel
Jan 26, 2016 at 12:56 PM
Hi again,

I managed to resolve this by instead invoking it as a InstalledFileAction:
project.AddAction(new InstalledFileAction("hide.cmd", "", Return.check, When.After, Step.InstallFiles, Condition.NOT_Installed) {
                   Impersonate = false,
                   Execute = Execute.deferred
                });
Leaving this here in case anyone else runs into the same issue :)
Marked as answer by Exodus on 1/26/2016 at 5:57 AM
Coordinator
Jan 27, 2016 at 12:33 AM
Great, txs.

For whom who is using ManagedSetup the AfterInsall event is also mapped as a deferred custom action. Thus you can just call the following code from the event handler:
static void project_AfterInstall(SetupEventArgs e)
{
    if (!e.IsUninstalling)
        Process.Start("attrib.exe", $"/s /h \"{session.Property("INSTALLDIR")}\"");
}
Marked as answer by Exodus on 1/27/2016 at 3:45 AM
Jan 27, 2016 at 10:45 AM
Edited Feb 10, 2016 at 1:12 PM
Wow, nice, didn't think of that.
Thanks oleg_s! :)

Update:
Your code was failing so I decided to improve it a bit, here's the final result:
private static void project_AfterInstall(SetupEventArgs e)
{
    if (!e.IsUninstalling)
    {
        try
        {
            Process RunAttrib = new Process();
            RunAttrib.StartInfo.UseShellExecute = false;
            RunAttrib.StartInfo.FileName = "attrib.exe";
            RunAttrib.StartInfo.CreateNoWindow = true;
            RunAttrib.StartInfo.WorkingDirectory = e.Session.Property("INSTALLDIR");
            RunAttrib.StartInfo.Arguments = "+s +h .";
            RunAttrib.Start();
            RunAttrib.WaitForExit();
        }
        catch (Exception ex)
        {
            e.Session.Log("ERROR: Failed to run attrib process with the following message: " + ex.Message);
        }
    }
}
Mar 17, 2016 at 8:20 AM
Edited Mar 17, 2016 at 8:24 AM
A follow up on this, since a few of our customers have been complaining on:
  1. In the scenario of InstalledFileAction, this displays a command window briefly, which can't be hidden (not even with the /q switch)
  2. In the scenario of the ManagedSetup package, it adds .NET dependency and can't be used (I know, silly customers who haven't deployed .NET in their environment)
I believe the QtCmdLineAction "bug" was due to a change in the WiX Toolset:
http://wixtoolset.org/documentation/manual/v3/customactions/qtexec.html
Prior to WiX v3.10, only CAQuietExec and CAQuietExec64 are available, which used the properties QtExecCmdTimeout (used for both 32-bit and 64-bit custom actions), QtExecCmdLine, and QtExec64CmdLine. Starting in WiX v3.10, those same identifiers are available but the new, preferred custom action names are WixQuietExec and WixQuietExec64 with properties named WixQuietExecCmdTimeout, WixQuietExec64CmdTimeout, WixQuietExecCmdLine, and WixQuietExec64CmdLine.
@Oleg, do you think it would be possible to investigate this and possibly fix the QtCmdLineAction issue? (Although note, I haven't tried re-adding QtCmdLineAction myself yet)
Coordinator
Mar 18, 2016 at 4:05 AM
Done. I just released v1.0.34.0 containing the new class WixQuietExecAction reflecting the new WiX approach.

Thank you for letting me know.
Marked as answer by Exodus on 3/18/2016 at 5:44 AM
Mar 18, 2016 at 12:45 PM
Edited Mar 18, 2016 at 12:46 PM
Awesome, my pleasure and thanks!

Did you update the NuGet package as well?
Coordinator
Mar 19, 2016 at 12:27 AM
Forgot. :)
Just did now. Txs