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

[James Hawkins]

On 2/7/07, Misha Koshelev <mk144210 at bcm.tmc.edu> wrote:
> On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote:
> > On 2/7/07, Misha Koshelev <mk144210 at bcm.tmc.edu> wrote:
> > > 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.
> > >
> >
> > You can't do this test by making the install fail, because you have no
> > way to check why the install failed.  Anything you test with the UI
> > sequence cannot present a UI to the user.  Why don't you just use a
> > custom action 51 in the install ui seq to set a property to some
> > value, and then make the condition of the component of an install file
> > the value of the property?  That way you can check if the file was
> > installed or not.  Either way, you're going to have to write a new
> > test function for this.
> >
>
> That sounds good. I actually made a new function doing what you said,
> and in testing under the wine MSI it works perfectly (writes specific
> file in UI mode but not in execute only mode, returns success,
> everything okay), but when I tried in XP I got a very weird behavior (or
> maybe not so weird). Specifically, XP MSI seems to reset the property
> between the UI sequence and execute sequence (no errors occur, but the
> file does not get written in UI sequence; if I take the condition out
> the file does get written; in fact I decided to make a custom action
> called StopMessage that displays the value of my property, that is
> simply a custom action 19, and in Wine MSI it displays my modified
> property value if I put it in the UI table or the execute table, but in
> Win XP MSI it only displays my modified value in the UI table, but in
> the Execute table it goes back either to blank or to the initial value
> if I define it in Properties; I even tried adding it to the
> SecureCustomProperties property but it did not help). Is this just a
> weird XP thing that I should just ignore and post my code as is, or is
> there some other way to set a property in the UI sequence that retains
> its value in the execute sequence in wine and XP? What if wine MSI
> decides to copy this behavior at a later date, my conformance test would
> not work anymore.
>

Well, by definition, that's not really a conformance test because it
doesn't conform to windows.  Did you make the property public and add
the property to the Property table?

http://msdn2.microsoft.com/en-us/library/aa370912.aspx

-- 
James Hawkins