Two files, same name, install type
I currently have two network install points for Adobe Acrobat Pro 8.1.6. I would like to have only one admin install. My issue is that depending on the install is what AdobeConfig.xml file gets deployed. This file is located in the following folder in the install point: program files\Adobe\Acrobat 8.0\Acrobat\alm_config_files There must be a simple way using a transform that I can place those two files in the same directory and depending on the transform that gets applied determines which AdobeConfig.xml file gets installed. In the file table this file is listed as
I need to be able to do this in Orca.
Acrobat_8.0_ALL_PS_RET.xml ALM_Config_File ADOBEC~1.XML|AdobeConfig.xml 67604 16385 5246
I need to be able to do this in Orca.
0 Comments
[ + ] Show comments
Answers (19)
Please log in to answer
Posted by:
anonymous_9363
14 years ago
So, my understanding is that you have 2 source files that end up, depending on circumstances, with the same name in a folder?
If that's the case, you could create two components containing the file and condition each with a property. If the property's value is '1' (or 'Yes' or 'True' - you choose) you get one version, if it's not '1' you get the other version. The property can be specified on the command line, by UI option (a radio button control with two options or a check-box) or by AppSearch.
The UI stuff will be excruciatingly painful using Orca/InstEdit.
If that's the case, you could create two components containing the file and condition each with a property. If the property's value is '1' (or 'Yes' or 'True' - you choose) you get one version, if it's not '1' you get the other version. The property can be specified on the command line, by UI option (a radio button control with two options or a check-box) or by AppSearch.
The UI stuff will be excruciatingly painful using Orca/InstEdit.
Posted by:
joedown
14 years ago
Would the two files reside in the same location in the Admin install point? How would the naming be handled since they both have the same name?
ORIGINAL: VBScab
So, my understanding is that you have 2 source files that end up, depending on circumstances, with the same name in a folder?
If that's the case, you could create two components containing the file and condition each with a property. If the property's value is '1' (or 'Yes' or 'True' - you choose) you get one version, if it's not '1' you get the other version. The property can be specified on the command line, by UI option (a radio button control with two options or a check-box) or by AppSearch.
The UI stuff will be excruciatingly painful using Orca/InstEdit.
Posted by:
joedown
14 years ago
Wouldn't it be a simpler approach if I could just overwrite the existing file when necessary? I would like to leave the normal installation as default and only change the special installation using a transform.
Posted by:
joedown
14 years ago
Anyone? Bueller? Can you deploy a file during install from an admin install point that is in a different location? Normally during install from an admin install point the files get deployed to the same folder and directory structure to the workstation as the install point. I think this could be accomplished using the duplicate file table but that seems overly complex to deploy one file. I'm just having problems with were this different source file for the special install will reside in the admin install point.
Posted by:
michaelnowell
14 years ago
I think that for an admin install you can only do what you want using the duplicate or move file tables. I can't see how you be able to have two files with the same name in the same location in an admin install.
I'd just name them AdobeConfig.xmlA and AdobeConfig.xmlB and then move them to where you want them using components and properties as VBScab suggested.
I'd just name them AdobeConfig.xmlA and AdobeConfig.xmlB and then move them to where you want them using components and properties as VBScab suggested.
Posted by:
turbokitty
14 years ago
Installshield Help:
Installing Files of the Same
NameInstalling Files of the Same Name
A component’s Source Location property names a subfolder where the component’s files will be stored in the source disk images, if the component’s files are not compressed. The component’s files will be copied to this subfolder in your release image. This property does not require a value, and in most cases, can be left blank. If you enter a value, it must be a valid Windows folder name. One instance where the Source Location property could be used is when you are creating an installation that contains more than one language. In this scenario, you can have multiple files with the same name. You can create a component for each language and set the Source Location property for each one. With the Source Location property set, any file with the same name can be copied onto the disk in two different locations, without the risk of being overwritten. For example, create two components called German and English. For the first component, set the Source Location property to GermanVersion. For the second, set the Source Location property to EnglishVersion. Create two files called Test.txt, giving them slightly different contents. Assign each file to a component. When you build your setup with uncompressed files, two separate folders on the disk images will be created, one called GermanVersion and one called EnglishVersion. Separate versions of Test.txt will be copied to each of these folders, but neither copy will be overwritten.
Note The Source Location property is not the same as the destination location. While it is conceivable that you might want to copy both versions of the file to the end user’s machine, it is more likely that you would want to filter the files by language
Installing Files of the Same
Name
A component’s Source Location property names a subfolder where the component’s files will be stored in the source disk images, if the component’s files are not compressed. The component’s files will be copied to this subfolder in your release image. This property does not require a value, and in most cases, can be left blank. If you enter a value, it must be a valid Windows folder name. One instance where the Source Location property could be used is when you are creating an installation that contains more than one language. In this scenario, you can have multiple files with the same name. You can create a component for each language and set the Source Location property for each one. With the Source Location property set, any file with the same name can be copied onto the disk in two different locations, without the risk of being overwritten. For example, create two components called German and English. For the first component, set the Source Location property to GermanVersion. For the second, set the Source Location property to EnglishVersion. Create two files called Test.txt, giving them slightly different contents. Assign each file to a component. When you build your setup with uncompressed files, two separate folders on the disk images will be created, one called GermanVersion and one called EnglishVersion. Separate versions of Test.txt will be copied to each of these folders, but neither copy will be overwritten.
Note The Source Location property is not the same as the destination location. While it is conceivable that you might want to copy both versions of the file to the end user’s machine, it is more likely that you would want to filter the files by language
Posted by:
joedown
14 years ago
I like what you have suggested. So I would assume than that this is accomplished by using the MoveFile table. It looks pretty straight forward Orignal filename, new filename, source dir, and dest dir. What is the relationship between the MoveFile table and the File table? Do I specify the file I want to deploy in the File table with the name AdobeConfig.xmlA or AdobeConfig.xml?
Thanks
Thanks
ORIGINAL: michaelnowell
I'd just name them AdobeConfig.xmlA and AdobeConfig.xmlB and then move them to where you want them using components and properties as VBScab suggested.
Posted by:
joedown
14 years ago
Update: It appears from further reading that the MoveFiles table only works for existing files on a workstation and cannot be used to manipulate files that are being installed. Can anyone confirm this? It's not clear on MSDN. I'm wondering if it might just be better to do a custom action to rename the file
Posted by:
anonymous_9363
14 years ago
Joe, that applies for normal installations, yes, but that's more due to the positioning of the two actions MoveFiles and InstallFiles. In your case, you may want to experiment with moving MoveFiles after InstallFiles.
Posted by:
joedown
14 years ago
I was able to fix this problem by using a VBscript to rename the file. This works for new installs but when reinstalling using REINSTALLMODE=vomus and REINSTALL=ALL the old file does not get overwritten with the new one. It does copy over the new file with the original name but does not rename it. Looking at the log I notice that it reports "skipping action: AdobeConfigDir (condition is false) so the script is not running. How do I figure out why it is false? I have no conditions set for the custom action in the InstallExecuteSequence table which means it should run whenever the installer is invoked right?
Posted by:
turbokitty
14 years ago
Do you want it to run on uninstall?
Put in a proper condition.
http://itninja.com/blog/view/appdeploy:-articles:-msi-advanced-custom-actions
Put in a proper condition.
http://itninja.com/blog/view/appdeploy:-articles:-msi-advanced-custom-actions
Posted by:
joedown
14 years ago
The problem is that it is not running at all during reinstall. I had a condition set to NOT Installed and removed it for testing expecting the script to run during reinstall. Is a condition needed to make it run during reinstall? It's working fine for a new install.
ORIGINAL: turbokitty
Do you want it to run on uninstall?
Put in a proper condition.
http://itninja.com/blog/view/appdeploy:-articles:-msi-advanced-custom-actions
Posted by:
turbokitty
14 years ago
I'm not sure. If you read that article I think it has a condition for repair that you can test.
Posted by:
joedown
14 years ago
Looking at the reinstall log it shows the following:
How do I figure out why the condition is evaluating to false? I tried changing the condition to NOT Installed OR MaintenanceMode="Modify"
Action start 11:04:47: SetRuntimeProperties.
MSI (s) (88:C4) [11:04:47:421]: Skipping action: SetAdobeConfigDir (condition is false)
MSI (s) (88:C4) [11:04:47:421]: Doing action: InstallInitialize
How do I figure out why the condition is evaluating to false? I tried changing the condition to NOT Installed OR MaintenanceMode="Modify"
Posted by:
turbokitty
14 years ago
Very interesting, are you sure your syntax is right?
Try "NOT REMOVE".
Case matters.
You should run it right after InstallInitialize if it's deferred (which it should be, or it'll run in the user context who might not have rights to make the change).
Try "NOT REMOVE".
Case matters.
You should run it right after InstallInitialize if it's deferred (which it should be, or it'll run in the user context who might not have rights to make the change).
Posted by:
joedown
14 years ago
I'm at a loss on this one. The action has to be after the installfiles since it would not be able to rename the file until after it exists on a new install and a reinstall copies over the original one that has the incorrect name. So the action needs to always run except during a complete uninstall. It just doesn't make sense unless it has something to do with the custom action type? It doesn't seem to matter what condition I set for the action it always evaluates to false.
ORIGINAL: turbokitty
Very interesting, are you sure your syntax is right?
Try "NOT REMOVE".
Case matters.
You should run it right after InstallInitialize if it's deferred (which it should be, or it'll run in the user context who might not have rights to make the change).
Posted by:
anonymous_9363
14 years ago
Silly question, Jow, but are you sure your transform is being applied? Also, can you run the MSI/MST through your authoring tool's debugger? You can then step through, watching the actions execute and property's values changing.
Posted by:
joedown
14 years ago
Figured it out. I was deleting the cached transform on the workstation I wanted to do the reinstall on. What I didn't realize is that the original transform on the network install point was getting applied even though I was specifying a new transform with a different name for the reinstall. I renamed the new transform to the original name on the network install point and ran the reinstall. It works like it should now. Are transforms really this tricky or am I making it more complicated... [:@]
ORIGINAL: VBScab
Silly question, Jow, but are you sure your transform is being applied? Also, can you run the MSI/MST through your authoring tool's debugger? You can then step through, watching the actions execute and property's values changing.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.