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

James Hawkins truiken at gmail.com
Wed Feb 7 13:23:30 CST 2007


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.

-- 
James Hawkins



More information about the wine-devel mailing list