msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

[Misha Koshelev]

On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote:
> On 2/7/07, Misha Koshelev <mk144210 at bcm.tmc.edu> wrote:
> > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote:
> > > On 2/7/07, Misha Koshelev <mk144210 at bcm.tmc.edu> wrote:
> > > > Hi, here is my proposed patch to the current msi MsiInstallProduct
> > > > consistency test that will make it's success depend on proper process of
> > > > UI flags (as well as everything else it depends on to make a successful
> > > > install). It seems to me like this is the simplest way to add this test
> > > > (it is only 5-6 lines added total), and it seems fair to me to add it to
> > > > this existing test for two reasons:
> > > > 1. The test is already testing a full product install (installs files,
> > > > services, registry values, etc) and my modification will simply result
> > > > in either no modification to these actions if UI level processing is
> > > > good or complete failure if it is bad, which will make the problem very
> > > > easy to diagnose.
> > > > 2. Looking through instructions on msdn it seems that there isn't a
> > > > kosher way to make a very simple MSI file that just, say, writes a
> > > > registry value (without doing costing, install validation, having a full
> > > > features table, installing some features, etc.) which would make a
> > > > separate function easy to implement and it does not really seem
> > > > necessary to copy and paste the whole test_MsiInstallProduct (or
> > > > similar) function just to check UI level processing.
> > > >
> > > > Changelog:
> > > >
> > > >         * msi: Make MsiInstallProduct conformance test depend on proper UI
> > > > level processing.
> > > >
> > >
> > > You need to put whatever you're trying to test into a new test
> > > function.  As-is, it's not clear what you're testing and we need to
> > > keep the tests logically separate.  Test both a success and a failure
> > > case, plus all the in between cases.
> > >
> > > > If the full UI is started (incorrectly)
> > > > +     * the InstallUISequence table will be used, and the install will fail. If the full UI is
> > > > +     * not started (correctly) the InstallExecuteSequence table will be used.
> > >
> > > Why does the install fail if we run the InstallUISequence action?.
> > > Also, InstallExecuteSequence runs no matter what so this comment would
> > > need to be fixed.
> > > a fa
> >
> > Weird, because it does indeed fail when running in full UI mode.
> >
> 
> It's failing because you don't have the InstallUISequence set up
> correctly.  I suggest you read through msdn about Windows Installer.
> 
> >
> > Do you know a better (more proper) way to do this then?
> >
> 
> Like I said before, I don't know what you're trying to do.  It wasn't
> obvious from the last patch.
> 
> >
> > I was researching this last night and I found either custom action 19 (this
> > number is off the top of my head) that will fail the install and display
> > a message or a failed Launch Condition which will also fail install and
> > display a message.
> >
> 
> Why do you want the install to fail?
> 
> > The custom action 19 (?) worked beautifully in my
> > tests, but the problem is that it display a dialog box if it thinks it
> > is in full UI mode and waits for the user to press okay, and if I
> > understand correctly user input like this is a no no in writing wine
> > conformance tests
> >
> 
> Correct.  No user intervention.
> 
> >
> > Do you have any suggestions for how to fail an
> > install in full UI mode without displaying a dialog box, or would this
> > be okay in the case of this specific conformance test?
> >
> 
> I don't know why you want the install to fail, so I don't have any suggestions.
> 

Ok sorry, I will make it clearer. The reason I am writing this
conformance test is to tickle the bug that my patch fixed earlier (6992)
in which the Vector NTI installer failed because MSI_InstallPackage was
not properly checking the UI level (using the mask) and so having any
flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE
was making it think a full graphical install was wanted (because
INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY >
INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so
that it would only work for a non-UI install (initiated by the actual
main MSI/installer which first sets the internal install level, and not
be the user clicking on one of the "child" MSIs), it would quit with a
message (custom action 19). I would like to make a consistency check
that checks this to make sure that MSI_InstallPackage does in fact check
the UI level correctly, taking the mask on the UILevel property into
account.

This, my original idea was to have a full install in the
ExecuteSequence, and have just one action in the UISequence that would
fail the install.  Thus, to test this check one would set the UI level
to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine
MSI to install the package. If the package succeeded, that means that
MSI_InstallPackage was checking the UI level correctly (as it does now
since my patch that fixed bug 6992), and everything would be installed.
Otherwise, it would fail, nothing would be installed, and we would know
that the consistency check failed and wine MSI was not properly checking
UI level flags  (as it was before my patch and as it would if some
regression occurred, e.g., changes in the MSI_InstallPackage code that
used the UI level without regard for the flags). So that is what I am
trying to do. Just write a conformance test that fails (in some kind of
proper way) in UI install but does not in the non-UI install in a way
that would be easy to determine with an ok(soemthing) statement.

Any advice would be appreciated. Thanks.

Misha