msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
Hi, just wanted to double-check with msi ppl and other wine developers if it's okay to add my conformance test to the test_MsiInstallProduct function. My reasons for doing this versus a completely separate test function are as follows: 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. I could do a separate function, it just seems unnecessary. Misha p.s. For some reason, I can't compile the msi crosstests (it gives an error on linking with -lcabinet, whereas, say, kernel32 crosstests compile file), so if anyone can crosstest it for me that would be great :) From 55b39a67676e2bd8c01c0b17b677298c9d22a46c Mon Sep 17 00:00:00 2001 From: Misha Koshelev [EMAIL PROTECTED] Date: Wed, 7 Feb 2007 08:10:19 -0600 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. --- dlls/msi/tests/install.c | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/dlls/msi/tests/install.c b/dlls/msi/tests/install.c index 00b7763..facd280 100644 --- a/dlls/msi/tests/install.c +++ b/dlls/msi/tests/install.c @@ -105,6 +105,12 @@ static const CHAR install_exec_seq_dat[] LaunchConditions\t\t100\n WriteRegistryValues\tSourceDir And SOURCEDIR\t5000; +/* as a proper check for INSTALLUILEVEL flags processing, make sure a UI install fails */ +static const CHAR install_ui_seq_dat[] = Action\tCondition\tSequence\n + s72\tS255\tI2\n + InstallUISequence\tAction\n + AllocateRegistrySpace\tNOT Installed\t1550\n; + static const CHAR media_dat[] = DiskId\tLastSequence\tDiskPrompt\tCabinet\tVolumeLabel\tSource\n i2\ti4\tL64\tS255\tS32\tS72\n Media\tDiskId\n @@ -231,6 +237,7 @@ static const msi_table tables[] = ADD_TABLE(feature_comp), ADD_TABLE(file), ADD_TABLE(install_exec_seq), +ADD_TABLE(install_ui_seq), ADD_TABLE(media), ADD_TABLE(property), ADD_TABLE(registry), @@ -689,6 +696,12 @@ static void test_MsiInstallProduct(void) create_test_files(); create_database(msifile, tables, sizeof(tables) / sizeof(msi_table)); +/* Make sure that the UI level flags are taken into account when determining whether to + * start a graphical UI or execute only mode (bug 6992). 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. */ +MsiSetInternalUI(INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCERESONLY, NULL); + r = MsiInstallProductA(msifile, NULL); ok(r == ERROR_SUCCESS, Expected ERROR_SUCCESS, got %u\n, r); -- 1.4.1
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On Wed, 2007-02-07 at 08:33 -0600, Misha Koshelev wrote: Hi, just wanted to double-check with msi ppl and other wine developers if it's okay to add my conformance test to the test_MsiInstallProduct function. My reasons for doing this versus a completely separate test function are as follows: 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. I could do a separate function, it just seems unnecessary. Misha p.s. For some reason, I can't compile the msi crosstests (it gives an error on linking with -lcabinet, whereas, say, kernel32 crosstests compile file), so if anyone can crosstest it for me that would be great :) Alright, got the crosstest to work, no new errors with and without my patch on Windows XP. Misha
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On 2/7/07, Misha Koshelev [EMAIL PROTECTED] 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. -- James Hawkins
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] 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. Do you know a better (more proper) way to do this then? 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. 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. 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? Thanks Misha
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] 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
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] 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
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] 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
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] 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
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
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 First of all, I added the Property to the Property table, which is, what I understand from that link (paragraph three I think) all that it takes to make it public (in fact, what happens when you go from UI to Execute is that the value of the property seems to be reset back to the value from the Properties table). Two things: 1) I am testing the behavior in UI mode to make sure the test works, but the actual test is to test the mode NONE | otherflags, which, before the bug fix, would result in a UI install, whereas in Windows (all versions) it would result in an execute-only install. This test breaks on wine without the patch to fix it, whereas it would execute on all Windows version without error, thus in this sense it conforms to Windows. The question is whether we are able to detect a failure to conform. 2) I tried on Win98 and in Win98 it works the same way it does on Wine. I will play with it some more, but because of these points it seems to me that it is still a reasonable test (it will succeed on all version of Windows, on Wine that properly detects UI flags, but fail on wine that does not detect UI flags; however, in the future, if wine MSI is made more like Win XP MSI, it would be possible that we will not be able to detect failure anymore). Misha
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
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 Aha, google search figured it out: * Property name ALL CAPS - passed from UI to execute. * otherwise not. Too bad it's not documented on msdn (you think they would...) Misha
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On Wed, 2007-02-07 at 23:46 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: 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 Aha, google search figured it out: * Property name ALL CAPS - passed from UI to execute. * otherwise not. Too bad it's not documented on msdn (you think they would...) Properties with names containing no lowercase letters are public properties... http://msdn2.microsoft.com/en-us/library/aa370905.aspx Too bad I don't read things carefully enough :) Anyway, I am sending the patch to wine-patches now. It is able to determine UI level properly (UI vs execute-only) on Win98, WinXP, and wine. Phew, time to go to bed. Misha
