Software Deployment

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.

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.

"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.

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?

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".

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?

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.