Hello,

what would you do if had a package which has to be updated frequently? I mean one of files from deployed package should be changed from time to time. What solution would you choose?
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
I would deploy that single file as a seperate install - by that I mean seperate from the main package in a different MSI then use standard update procedures to target this MSI.

A classic example of this would be a config file which changes frequently.
Answered 07/27/2005 by: DavidLock
Senior Yellow Belt

Please log in to comment
0
That's often the best way to go. Another option is to patch via an Administrative Install Point, or just distribute MSPs, but if there are many constant updates and each wipes out all previous updates, the separate package is the way to go.

For example, I have an app (a really poorly concieved app, actually) that needs access to a resource that we do not want the user to have general access to. The ID/PW is kept in a local encrypted file that's updated quarterly. I don't care about previous ID/PW files, I just want the current one out there and nothing else. For that, I have two MSI's.

APPLICATION.MSI
APPLICATION-CONFIG-2005Q1.MSI
APPLICATION-CONFIG-2005Q2.MSI... etc.

I make sure that all the APPLICATION-CONFIG-xxxxQx.MSI files have the same upgrade code and are properly versioned. (I happen to use 1.0.2005.1, 1.0.2005.2.. etc. Use any format that properly sequences the versions in a logical manner. With the same upgrade code in all versions, I can add that code to each version's Upgrade Table and configure it to perform a Major Upgrade for all previous versions. That removes all previous versions during the install.
Answered 07/27/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
"have the same upgrade code and are properly versioned. (I happen to use 1.0.2005.1, 1.0.2005.2"

Does that versioning scheme work? I thought MSI only reads the first three parts of a product version and ignores everything after.
Answered 07/27/2005 by: DavidLock
Senior Yellow Belt

Please log in to comment
0
ORIGINAL: VikingLoki

With the same upgrade code in all versions, I can add that code to each version's Upgrade Table and configure it to perform a Major Upgrade for all previous versions. That removes all previous versions during the install.


That's a very basic explanation. The part about removing all previous versions I mean. If you are sure all of your components are aligned the result will be what you are expecting, redundant components uninstalled (remember this happends last) and registry will reflect only one version of the package installed.

However, if you know you are only changing one file therefore only the content of one component I don't see the need for any separate MSI's, just keep deploying upgrade packages as the MSI upgrade process will work just as efficiently on the master package without the confusion of having an application made from more than one MSI.

Or am I misunderstanding something?
Answered 07/27/2005 by: GB1
Orange Belt

Please log in to comment
0
ORIGINAL: GB1
However, if you know you are only changing one file therefore only the content of one component I don't see the need for any separate MSI's, just keep deploying upgrade packages as the MSI upgrade process will work just as efficiently on the master package without the confusion of having an application made from more than one MSI.

Or am I misunderstanding something?


You're correct, but make sure that "RemoveExistingProduct" is placed last in the "InstallExecuteSequence".
Answered 07/28/2005 by: AngelD
Red Belt

Please log in to comment
0
ORIGINAL: VikingLoki

That's often the best way to go. Another option is to patch via an Administrative Install Point, or just distribute MSPs, but if there are many constant updates and each wipes out all previous updates, the separate package is the way to go.

For example, I have an app (a really poorly concieved app, actually) that needs access to a resource that we do not want the user to have general access to. The ID/PW is kept in a local encrypted file that's updated quarterly. I don't care about previous ID/PW files, I just want the current one out there and nothing else. For that, I have two MSI's.

APPLICATION.MSI
APPLICATION-CONFIG-2005Q1.MSI
APPLICATION-CONFIG-2005Q2.MSI... etc.

I make sure that all the APPLICATION-CONFIG-xxxxQx.MSI files have the same upgrade code and are properly versioned. (I happen to use 1.0.2005.1, 1.0.2005.2.. etc. Use any format that properly sequences the versions in a logical manner. With the same upgrade code in all versions, I can add that code to each version's Upgrade Table and configure it to perform a Major Upgrade for all previous versions. That removes all previous versions during the install.


What tool do you use for preparing that upgrades?
Answered 07/28/2005 by: Wozik
Orange Belt

Please log in to comment
0
An upgrade package is build the same way as you build your regular msi packages, so use your standard packaging tool which could be Installshield AdminStudio, Wise Packaging Studio or even ORCA if that's what you use.
Answered 07/28/2005 by: AngelD
Red Belt

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