[wix-users] MsiEvaluateCondition

Phill Hogland phill.hogland at rimage.com
Mon Nov 30 06:50:13 PST 2015


I have found using Lux/Nit to be helpful beyond just for testing immediate custom actions that I intend to use in my msi packages.  When I need to test a CA function that I may plan to use in a deferred action, or if I needed to test a Condition syntax, I create a simple immediate action to call the function and then drive it with a Lux test project.  Also we have windowed applications which are run as a service successfully, as long as they never show a modal dialog (or there is code that detects and responds to the modal dialog, in the non-interactive desktop).  If another application plans to use Windows messages to communicate with the service app then it must be in the same Winstation\desktop context.

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Douglas, Keith (STATCAN/STATCAN)
Sent: Friday, November 27, 2015 2:23 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: [wix-users] MsiEvaluateCondition

I was looking at both the native MsiEvaluateCondition and its DTF counterpart for use in an Condition syntax validation tool for my WiX front end. I see that the first seems to require an open package, hence a legitimate package. By contrast the DTF version requires a Session to work in. I don't care about making sure Properties etc. are recognized or environment variables resolve, just that the syntax is correct. Is there another way to validate Condition syntax without using a package or Session (which I take it would require an installation context, which I don't want)? Not really a big deal if not, but it would be nice to understand the dependencies of the tools I build. (I do know the package does not have to be installed.)

In case it matters, the code idea I had to use the native method is - calling CheckMsiCondition for the purpose mentioned above:

    public static class NativeMethods
    {
        [DllImport("msi.dll", CharSet = CharSet.Unicode)] static extern uint MsiEvaluateCondition(int hInstall, string szCondition);
        [DllImport("msi.dll", CharSet = CharSet.Unicode)] static extern uint MsiOpenPackageEx(string szPackagePath, uint dwOptions, out int hProduct);
        [DllImport("msi.dll", CharSet = CharSet.Unicode)] static extern uint MsiCloseHandle(int hAny);

        public static bool CheckMsiCondition (string whatToCheck)
        {
            int handle;
            uint result = MsiOpenPackageEx("[path to some existing MSI deleted]", (uint)0, out handle); // Use demo MSI for now.
            result = MsiEvaluateCondition(handle, whatToCheck);
            MsiCloseHandle(handle);
            return (result == 0 || result == 1);
        }
    }

Finally, I note that calling MsiOpenPackageEx seems to provoke the standard msiexec UI for installing a product anyway. Would this rule out using the call in a service even if the appearance is temporary/not used?


Keith Douglas
Programmer Analyst | Programmeur analyste Questionnaire Development Services - CAI Social | Services de développement de questionnaires - IAO Social Jean Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 Keith.Douglas at canada.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada




____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/



More information about the wix-users mailing list