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

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

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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.
Answered 07/02/2009 by: VBScab
Red Belt

Please log in to comment
0
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.

Answered 07/02/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
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.
Answered 07/06/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
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.
Answered 07/08/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
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.
Answered 07/08/2009 by: michaelnowell
Second Degree Blue Belt

Please log in to comment
0
Installshield Help:

Installing Files of the Same
Name 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
Answered 07/08/2009 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
0
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

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.


Answered 07/08/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
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
Answered 07/10/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
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.
Answered 07/20/2009 by: VBScab
Red Belt

Please log in to comment
0
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?
Answered 07/22/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
Do you want it to run on uninstall?

Put in a proper condition.

http://itninja.com/blog/view/appdeploy:-articles:-msi-advanced-custom-actions
Answered 07/22/2009 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
0
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

Answered 07/22/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
I'm not sure. If you read that article I think it has a condition for repair that you can test.
Answered 07/22/2009 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
0
Looking at the reinstall log it shows the following:


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"
Answered 07/24/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
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).
Answered 07/24/2009 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
0
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).


Answered 07/24/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
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.
Answered 07/27/2009 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 07/27/2009 by: joedown
Second Degree Brown Belt

Please log in to comment
0
The latter. [:D]

Good job figuring it out.
Answered 07/27/2009 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity