‎Jul 23, 2007 04:12 PM
‎Jul 23, 2007 06:21 PM
Cary R wrote:
If I'm understanding you right, these custom actions are basically wrapping another installer, and handling maintenance configuration of an XML file.
Assuming I'm understanding you correctly, you could easily enough handle this with a single MSI file. Basically, you would create a 'System Search' to find the folder (Installation Designer -> Behavior and Logic -> System Search), and then store the folder path in a property (i.e. FOLDERFOUND), then use the property in the following conditions:
Action 1 condition (folder doesn't exist): NOT FOLDERFOUND
Action 2 condition (folder exists): FOLDERFOUND
‎Jul 23, 2007 07:47 PM
nommos wrote:
Yes basically the 2 vbscripts edit the configuration of an xml file. The first VBScript edits changes to an XML file upon an upgrade. The second script edits the file with new numbers and places those in the correct area of the xml files being edited.
Now I had already created a System Search String before seeing this reply, so I am following you there. I am pretty sure you are understanding what I am trying to accomplish. And REALLY appreciate it. 😄
Questions:
Do I need to create "FOLDERFOUND" in the property table?
What I would like to do is:
Action 1 condition (folder doesn't exist): NOT FOLDERFOUND
If folder does not exist goto custom action NewInstall.vbs
Action 2 condition (folder exists): FOLDERFOUND
If folder(s) exist goto custom action upgrade.vbs
Thanks again for any help! I really appreciate it.
‎Jul 24, 2007 10:00 AM
‎Jul 24, 2007 11:36 AM
‎Jul 24, 2007 12:42 PM
Cary R wrote:
Ahh, I see where you're getting confused here.
So, at the end of the system search wizard, you'll get a list of properties that already exist in the Property table. You'll want to type your own unique property here at this point, so something like 'DDXFOUND' would work.
Then, when you're creating conditions in the Condition Builder, only a few of the most commonly used properties are available. You'll just want to type in the name of your property that you used before.
‎Jul 24, 2007 05:28 PM
‎Jul 24, 2007 05:56 PM
‎Jul 24, 2007 06:23 PM
‎Jul 25, 2007 09:15 AM
‎Jul 25, 2007 09:29 AM
‎Jul 25, 2007 10:17 AM
‎Jul 25, 2007 10:28 AM
Cary R wrote:
Sure, I could take a look at the log. I've looked at enough of them that it would be pretty quick to see where the issue is. There should be a paperclip icon available to attach a file when you make a post, so you can just upload it directly here.
‎Jul 25, 2007 11:14 AM
‎Jul 25, 2007 11:28 AM
‎Jul 25, 2007 11:44 AM
‎Jul 25, 2007 12:27 PM
Cary R wrote:
Here's the guilty entry from the logfile:
Action start 10:47:51: Upgrade.
MSI (s) (B4:88) [10:47:51:888]: Note: 1: 1720 2: Upgrade 3: -2146828235 4: Microsoft VBScript runtime error 5: File not found 6: 76 7: 1
1720 means that the vbscript action couldn't be run because the *.vbs file wasn't present where it was expected.
Did you say that the Upgrade action had the VBScript stored directly in the action itself? Because this would be more characteristic of if it was configured to run a file that was installed with the product, or already existing on the system.
‎Jul 25, 2007 01:01 PM
‎Jul 25, 2007 03:43 PM
‎Jul 25, 2007 05:09 PM
Cary R wrote:
Whoops! I missed that entry.
So, your question about Maintenance mode. Would this involve a third action? And if so, what would the difference between Maintenance and an Upgrade be? since launching the MSI from either ARP or from the existing MSi would both technically be maintenance.
‎Jul 26, 2007 02:49 PM