This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Set Always Overwrite property via automation
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 10, 2010
01:47 PM
Set Always Overwrite property via automation
Hello folks,
IS 2010 Professional.
Basic MSI (Merge module actually)
Here's the deal.
I have a VBScript which creates component description inside of a merge module, based on the contents of a specific folder.
(We pile all of our objects into this folder and then my VBScript reads the names of each object in the folder and creates component of the same name.)
After some struggling, I figured out how to set the “Always Overwrite” option when I create a new components.
This following code works for me:
Assume for the following example, that "pComponent" already contain a reference to a component.
pComponent.ISWiFiles(1).OverrideSystemVersion = True
pComponent.ISWiFiles(1).Version = "65535.0.0.0"
Note: I needed to use the index number (1) instead of the key file, because I couldn’t figure out how to acquire the key file.
(Direct editor \ File table \ File column)
In any event, things work well enough, when my VBScript adds new components and sets the "Always Overwrite" attribute perfectly.
But I'm having a bit of trouble setting the “Always overwrite” attribute for an "existing" component inside of the project.
My VBScript can tell if a component already exists inside of the project.
When I try and execute either of the above two commands, my VBScript behaves as if the commands are not valid.
It’s like automation is saying “This isn’t valid. Good bye”.
No error messages.
Nothing.
Note:
I experience the exact same behavior if I use anything except (1) in the above example, when I am adding new components.
I opened an InstallShield incident a couple of days ago but sometimes, they can be a bit poky.
Priorities I guess.
Has anyone been able to successfully use automation to modify the “Always Overwrite” attribute of a file, on a Basic msi (merge module) ?
If so, would you consider sharing an example of your code ?
Thanks in advance for any responses.
Ray in Wisconsin
IS 2010 Professional.
Basic MSI (Merge module actually)
Here's the deal.
I have a VBScript which creates component description inside of a merge module, based on the contents of a specific folder.
(We pile all of our objects into this folder and then my VBScript reads the names of each object in the folder and creates component of the same name.)
After some struggling, I figured out how to set the “Always Overwrite” option when I create a new components.
This following code works for me:
Assume for the following example, that "pComponent" already contain a reference to a component.
pComponent.ISWiFiles(1).OverrideSystemVersion = True
pComponent.ISWiFiles(1).Version = "65535.0.0.0"
Note: I needed to use the index number (1) instead of the key file, because I couldn’t figure out how to acquire the key file.
(Direct editor \ File table \ File column)
In any event, things work well enough, when my VBScript adds new components and sets the "Always Overwrite" attribute perfectly.
But I'm having a bit of trouble setting the “Always overwrite” attribute for an "existing" component inside of the project.
My VBScript can tell if a component already exists inside of the project.
When I try and execute either of the above two commands, my VBScript behaves as if the commands are not valid.
It’s like automation is saying “This isn’t valid. Good bye”.
No error messages.
Nothing.
Note:
I experience the exact same behavior if I use anything except (1) in the above example, when I am adding new components.
I opened an InstallShield incident a couple of days ago but sometimes, they can be a bit poky.
Priorities I guess.
Has anyone been able to successfully use automation to modify the “Always Overwrite” attribute of a file, on a Basic msi (merge module) ?
If so, would you consider sharing an example of your code ?
Thanks in advance for any responses.
Ray in Wisconsin
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 13, 2010
06:37 PM
Could you use ISWiComponent.KeyPath? From the "ISWiComponent Object" help topic:
When the key path is a key file, it contains the file key. [...] The file key is the same as the Name property of an ISWiFile object.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 14, 2010
02:47 PM
Thanks for the reply.
And for the suggestion.
Here's what “DOES” work, for me.
In my VBScript I open the project, create a new Component with the same name as the file that will be associated with it and then add the file.
I set a number of component and file properties in this script.
IE:
pComponent.RegistrationType = -2 for COM extract at build set to Yes
pComponent.RegistrationType = 0 for COM extract at build set to No
pComponent.SharedDLLRefCount = bShared for sharing
pComponent.Destination = strInstallDir for target pc destination
pComponent.KeyPathType = 2 for key path type
And finally, pComponent.KeyPath = pComponent.ISWiFiles(1).Name for the key path
Note that in the above KeyPath statement I still need to use an index number(1) in order for the component to be added to the merge module successfully.
If I choose to "set" the “Always Overwrite” attribute, the following two sets of constructs work equally well. (For me.)
pComponent.ISWiFiles(1).OverrideSystemVersion = True
pComponent.ISWiFiles(1).Version = "65535.0.0.0
Or
pComponent.ISWiFiles(pComponent.ISWiFiles(1).Name).OverrideSystemVersion = True
pComponent.ISWiFiles(pComponent.ISWiFiles(1).Name).Version = "65535.0.0.0"
But in both cases, it seems that I need to include a file index number (1).
If I don't include the file index number, my VBScript simply stops at that point and falls through to the next function.
No components are added to my merge module.
.
It's almost as if automation, has determined that "something" is wrong (I'm thinking, but can't prove, that it's a syntax issue) and simply ends.
Try as I might to incorporate your suggestion into my script, I can't manage to pull it off.
I even tried hard coding the key file into my script.
With and without double quotes.
And I tried hard coding the file name instead of the key file designation.
But to no avail.
No doubt I am overlooking something.
(Wouldn't be the first time.)
Fortunately, for me, 99.9 % of my components only have one file associated with them.
So using the file index number (1) works fine.
For my “problem child” components (those with multiple files associated with them).
Until I can figure out how to make this work using key file designations instead on file index numbers (1), I'll simply have to change them by hand. (So as to set the "Always Overwrite" attribute.
Thanks again for the quick response and the suggestion.
I'll continue to "play" with this.
If I DO find something that works, I'll update this post so that an audit trail will exist, for anyone else experiencing a similar issue.
Thanks for your time with my issue.
Ray in Wisconsin
And for the suggestion.
Here's what “DOES” work, for me.
In my VBScript I open the project, create a new Component with the same name as the file that will be associated with it and then add the file.
I set a number of component and file properties in this script.
IE:
pComponent.RegistrationType = -2 for COM extract at build set to Yes
pComponent.RegistrationType = 0 for COM extract at build set to No
pComponent.SharedDLLRefCount = bShared for sharing
pComponent.Destination = strInstallDir for target pc destination
pComponent.KeyPathType = 2 for key path type
And finally, pComponent.KeyPath = pComponent.ISWiFiles(1).Name for the key path
Note that in the above KeyPath statement I still need to use an index number(1) in order for the component to be added to the merge module successfully.
If I choose to "set" the “Always Overwrite” attribute, the following two sets of constructs work equally well. (For me.)
pComponent.ISWiFiles(1).OverrideSystemVersion = True
pComponent.ISWiFiles(1).Version = "65535.0.0.0
Or
pComponent.ISWiFiles(pComponent.ISWiFiles(1).Name).OverrideSystemVersion = True
pComponent.ISWiFiles(pComponent.ISWiFiles(1).Name).Version = "65535.0.0.0"
But in both cases, it seems that I need to include a file index number (1).
If I don't include the file index number, my VBScript simply stops at that point and falls through to the next function.
No components are added to my merge module.
.
It's almost as if automation, has determined that "something" is wrong (I'm thinking, but can't prove, that it's a syntax issue) and simply ends.
Try as I might to incorporate your suggestion into my script, I can't manage to pull it off.
I even tried hard coding the key file into my script.
With and without double quotes.
And I tried hard coding the file name instead of the key file designation.
But to no avail.
No doubt I am overlooking something.
(Wouldn't be the first time.)
Fortunately, for me, 99.9 % of my components only have one file associated with them.
So using the file index number (1) works fine.
For my “problem child” components (those with multiple files associated with them).
Until I can figure out how to make this work using key file designations instead on file index numbers (1), I'll simply have to change them by hand. (So as to set the "Always Overwrite" attribute.
Thanks again for the quick response and the suggestion.
I'll continue to "play" with this.
If I DO find something that works, I'll update this post so that an audit trail will exist, for anyone else experiencing a similar issue.
Thanks for your time with my issue.
Ray in Wisconsin
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 14, 2010
03:52 PM
In a quick coffee-break test, this seems to work:
Running cscript /nologo autokeyfiletest.vbs seems to set the file properties...
set oISM = CreateObject("ISWiAuto16.ISWiProject")
oISM.OpenProject("AutoKeyFileTest.ism")
for each comp in oISM.ISWiComponents
set thisKeyFile = comp.ISWiFiles(comp.KeyPath)
' TODO: should make sure component even has a key file
' TODO: not that it matters, but shouldn't display version for unversioned file
Wscript.Echo "In component " & comp.Name & ", changing " & thisKeyFile.DisplayName & _
" from version " & thisKeyFile.Version
thisKeyFile.OverrideSystemVersion = True
thisKeyFile.Version = "65535.0.0.0"
next ' comp
oISM.SaveProject
oISM.CloseProject
Running cscript /nologo autokeyfiletest.vbs seems to set the file properties...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 15, 2010
08:52 AM
Thanks once again for your time AND the detailed reply.
I'm happy to report that, based on the content of your last posting, I am now able to successfully set the "Always Overwrite" attribute using the "Key Path" rather than a file index number.
AND, I can do this, not only for NEW components (and their related files) but for existing components (within a merge module) as well.
The "key", (no pun intended) was:
set thisKeyFile = comp.ISWiFiles(comp.KeyPath)
thisKeyFile.OverrideSystemVersion = True
thisKeyFile.Version = "65535.0.0.0"
It never occurred to me, that I could "code" things, in such a way.
"Seeing" an example of code that actually works, is powerful indeed.
Thank you once again for your time with MY issue.
I DO appreciate it.
Ray in Wisconsin
I'm happy to report that, based on the content of your last posting, I am now able to successfully set the "Always Overwrite" attribute using the "Key Path" rather than a file index number.
AND, I can do this, not only for NEW components (and their related files) but for existing components (within a merge module) as well.
The "key", (no pun intended) was:
set thisKeyFile = comp.ISWiFiles(comp.KeyPath)
thisKeyFile.OverrideSystemVersion = True
thisKeyFile.Version = "65535.0.0.0"
It never occurred to me, that I could "code" things, in such a way.
"Seeing" an example of code that actually works, is powerful indeed.
Thank you once again for your time with MY issue.
I DO appreciate it.
Ray in Wisconsin