[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