how to handle these Patch scenarios

[clhug42]

Hopefully I can explain this well enought to understand. We've been doing this for years by other means but I'm trying to convert this to fully InstallShield and MSI based.

We've got software that we do big updates to every 2 months. (I don't want to say "major" updates because they aren't "major" in the sense of what a "major update" means to InstallShield and MSI, so I say "big". I guess technically it corresponds to a "minor" update in InstallShield/MSI terminoligy.)

Today we just always deploy a full package every time to update it. But we're moving from a CD-ROM based distribution to an electronic download distribution, so we want to reduce the size of the files required to download for those updates. Thus, I'm looking to "patch" updates for users who already have the previous version installed so they only have to download the patch rather than the full package. That part of it I think is relatively straight forward. I'd use the "Patch Design" view to build a patch.

The next part of this though is that several times between these bi-monthly "big" updates, we do "small" updates. The software does financial calculations and we update some of the data files that the software uses as a basis for the calculations so we stay current with the market. (Like interest rates and the like.) I'd like to do Quick Pathces for these. My thought is to do a quick patch that does not change the version, even the minor version (3rd digit), and the files are marked as Always Overwrite in the patch.

So my first question is, will that work okay, doing Quick Patches for those "small" unversioned updates between the big updates, then doing a Patch Design type patch for the "big" update every 2 months? Any conflicts between Quick Patch patches and Patch Design patches?


My second question is in regards to these small updates for the data files. When we're testing the upcoming big bi-monthly release, our QA people have special versions of those data files that they put in so calculation results from the software match specific test cases in their regression testing. These are the same files, just with different values. So I'd have a special Quick Patch of these files just for our QA people. The issue is that during a development cycle of each bi-monthly release, we rebuild the installs (.msi's) for the software each week to pick up new programming changes. When we do that, we bump the minor version (3rd digit) of the .msi each time we build it. That means that every time we rebuild the msi, we have to also rebuild this QA version of the Quick Patch for the data files, even though the files in that Quick Patch haven't changed (remember, they're marked as always overwrite so they still contain the full files).

When doing a Patch Design patch, there's a setting in there to tell it what piece of the version number of the product you're patching to match against, all 3 pieces (major, minor, build) or just the first 2 pieces, or just the major number. Is there a way to do that with Quick Patches? If I could tell it to ignore the build number, I wouldn't have to rebuild that QA Quick Patch every time we rebuild the MSI's. (This would also be a heck of a lot easier if there were Automation support for Quick Patch, but there isn't.)

Thank you!

[Cary_R]

Hi There,

Patching is easily the most complicated thing you can do with Windows Installer. So bear with me if this post seems long-winded.

--Where possible, you want to try and use the Patch Design view, since this will make things easier when trying to exercise very precise control over what's going on during the build process of your patches.

--You really want to be using the latest version of InstallShield because you get "Best Practice" dynamic file links (which avoid breaking component rules when automatically creating new components), and as well the new style of Quickpatches that also avoid some of the weird behaviors that can cause problems.

--In a Quickpatch, the 'Always Overwrite' setting is assuming that the target file is unversioned, and it just gives it a version of 1.0.0.0 instead of 65535.0.0.0 like in a regular MSI project.

As far as "Conflicts", there's not really much in the way of conflicts that I'm aware of, at least with the new style of quick patches (the old style created new subfeatures and components, which had some limitations). You will likely want to use a particular flag in your patch configuration since this will clear out previous patches from the View of the MSI when applying your "Big" update:

Minor Update to Target RTM Version (MSI 3.1 Required)
http://kb.flexerasoftware.com/doc/Helpnet/installshield16helplib_sp1/PatchConfigAdvanced.htm

For QuickPatch projects, you're correct that the setting for the version relationship isn't exposed. The setting lives in a *.pcp file that gets stored in 'QuickPatch.pcp' in the 'Interm' folder. It'll be the 'TargetImages' table's ProductValidateFlags column as documented here:

http://msdn.microsoft.com/en-us/library/aa372066(VS.85).aspx

For setting this via automation, you can manually update the value using MSI automation:

http://msdn.microsoft.com/en-us/library/aa368568(VS.85).aspx

The last talking point here is that you'll want to make sure to build each quickpatch based off of the previous QuickPatch. This will ensure that each is applicable in a cumulative fashion (allowing you to apply only the latest quickpatch or the all in sequence).

Hope this gets you started!

Regards,

Cary

[clhug42]

Thank you Cary. I appreciate the response. Don't worry about being long-winded. I have a feeling my original post, and this reply, are pretty long-winded themselves. I'm grateful for any information I can get and the more detailed the better.

First, I'll say that we're on InstallShield 2008 and unfortunately, upgrading isn't an option any time soon. Also, right now we're trying to target only Windows Installer 2.0. (Targeting previous patches isn't a problem so I'm not worried about that flag that removes previous patches first.)

I should also maybe mention, the files we're replacing with these QuickPatches ARE UNversioned, AND are NOT binary. They are all things like Access .mdb files, .xml files, and other files like that, where a "version" isn't really even relevant.

I've been looking at the Windows Installer automation, but haven't quite figured it out yet. I just have to dig through it more though and I'll figure it out.

Is there any documentation anywhere on exactly what QuickPatch actually does? I mean the internal workings of the steps it actually goes through (not just the general Help info that gives a high-level overview of what it does). I've been looking at it myself and figured some of it out on my own, and noticed how it adds new subfeatures and components and wondered why it did that. I was concerned if those new subfeatures or components created by the quickpatch would cause issues with a later upgrade install or Patch Design View patch since components wouldn't match up for the same files.

Also, since there is no InstallShield automation for QuickPatch, my thought is to basically try to duplicate QuickPatch functionality using Windows Installer's own automation. So again, if there's any documentation on what QuickPatch does it would help me have a better idea of if what I'm thinking based on my own investigating is correct or not, or how I might do things differently (like avoid the subfeatures and components).

I've manually walked through this example from MSDN of manually creating a patch. One issue I ran into is that, as mentioned above, because the files I'm updating are unversioned, I have to change the hashes for the files in the MSIFileHash table. This example doesn't talk about how to do that. If I'm manually directly editing the .msi file using either the InstallShield IDE or Orca, I can't figure out how to generate the hash for the updated file to put into the updated .msi. If I'm able to automate this though through Windows Installer automation I imagine there's a function to call that will update the hash.
http://msdn.microsoft.com/en-us/library/aa367816(VS.85).aspx



Yeah, for the quickpatches in our production environment where we have the small updates of data files every few weeks, I definitely already planned to target each new patch over the original install AND the in-between Quickpatches.

I have a question regarding a comment from your previous reply:
"--In a Quickpatch, the 'Always Overwrite' setting is assuming that the target file is unversioned, and it just gives it a version of 1.0.0.0 instead of 65535.0.0.0 like in a regular MSI project."

According to the description of what I see in the InstallShield ID for that checkbox in a QuickPatch project, the Always Overwrite option also tells it to include the whole file in the patch rather than a binary difference, so apparently it can overwrite any older version. So is that true?

So back to the above comment about targeting previous Quickpatches with later Quickpatches. While I intended to do that, IF the Always Overwrite option does include the whole file in the quickpatch, the if I use that option, do I really need to target previous quickpatches?



Another comment from your previous reply:
"For QuickPatch projects, you're correct that the setting for the version relationship isn't exposed. The setting lives in a *.pcp file that gets stored in 'QuickPatch.pcp' in the 'Interm' folder. It'll be the 'TargetImages' table's ProductValidateFlags column"

So is there a way to interject into the QuickPatch build process after InstallShield creates the QuickPatch.pcp file, that I can then modify that file, then let InstallShield finish building the actual patch?



Last (for now), regarding targeting previous patches when building a new patch, when building QuickPatches on top of each other it's very easy to target previous QuickPatches. But as I mentioned in my first post, when it comes to the bi-montly bigger updates (equivalent of a "minor" update in IS & MSI terms) I plan to use the Patch Design view. I don't see how to target previous QuickPatches from the Patch Design view.

Thanks again!

[Cary_R]

To focus on a few things you said here:

Is there any documentation anywhere on exactly what QuickPatch actually does? I mean the internal workings of the steps it actually goes through (not just the general Help info that gives a high-level overview of what it does). I've been looking at it myself and figured some of it out on my own, and noticed how it adds new subfeatures and components and wondered why it did that. I was concerned if those new subfeatures or components created by the quickpatch would cause issues with a later upgrade install or Patch Design View patch since components wouldn't match up for the same files.

Not too much documentation. But the short version is this:

--Creates a copy of the original MSI package in a folder called "UpgradedImage", but removes all the files. This forces only the files you include in the IDE to be picked up during the patch build.

--When new files are added, each gets a subfeature and component associated with it. There's no strict requirement for doing it this way, which is why the "New" style quickpatches don't do this. As long as you're careful with file versioning, your files will get updated correctly.

--New or updated files are the only files present in the uncompressed UpgradedImage folder. Although, you'll have to update their MSI Table information manually (mostly, Version, Size, Language, and the file hash).

Check out:

http://msdn.microsoft.com/en-us/library/aa369426(VS.85).aspx

Specifically, "File Query Functions" will give you functions for this.


--With the old quickpatches, shortcuts can get messed up if they point to the updated files in the quickpatch (since advertised shortcuts point to a component, and the component's registered feature changes). Custom actions are inserted to help fix up this and other small issues (ISQuickPatchHelper.dll if I recall correctly). This isn't necessary if you're not using the trick with the subfeatures.

--Lastly, it builds up a *.pcp file that describes the previous targeted setups, and as well the options for the current setup (I mentioned this before, QuickPatch.pcp), and it hands this file off to the MSI Patch API (UiCreatePatchPackage()).

According to the description of what I see in the InstallShield ID for that checkbox in a QuickPatch project, the Always Overwrite option also tells it to include the whole file in the patch rather than a binary difference, so apparently it can overwrite any older version. So is that true?

This would be true.

So back to the above comment about targeting previous Quickpatches with later Quickpatches. While I intended to do that, IF the Always Overwrite option does include the whole file in the quickpatch, the if I use that option, do I really need to target previous quickpatches?

You'll still need to target previous patches, not because it's as simple as file overwriting that is at issue, but more the state of the MSI Database View when applying the new patch. Not targeting all previous patches opens you up to the view having unexpected conditions present, for example table rows that are already present/missing when they are trying to be deleted/created. These cause runtime errors when this occurs, but in some cases the patch appears to run OK.

Even without errors, it's really a scenario you have to worry about, since you can never be quite sure if there were other issues introduced because the target MSI was out of sync with the *.mst files meant to upgrade it to a particular state.

So is there a way to interject into the QuickPatch build process after InstallShield creates the QuickPatch.pcp file, that I can then modify that file, then let InstallShield finish building the actual patch?

Sorry for being unclear on this one. You'd modify the *.pcp file, and then hand it off to the Microsoft Patch API. Or, I believe the InstallShield Automation has the ability to build based off of a *.pcp file as well:

http://kb.flexerasoftware.com/doc/Helpnet/installshield12helplib/IHelpAutoBuildPCPFile.htm

I don't see how to target previous QuickPatches from the Patch Design view.

Thankfully, this is an easy one. You browse to the "UpgradedImage" folder, which is what's used to build the QuickPatch off of. A patch at its core is just the difference between 2 databases (in the form of 2 or more *.mst files) wrapped up in the *.msp as a container for the transforms.

[clhug42]

Thanks again! Great information! I really appreciate it!!!

Cary R wrote:
Not too much documentation. But the short version is this:

Yep, those 3 steps are essentially what I figured out. Thanks for confirming. Couple follow-up questions though.

Cary R wrote:
--Creates a copy of the original MSI package in a folder called "UpgradedImage", but removes all the files. This forces only the files you include in the IDE to be picked up during the patch build.

In opening the copied and updated MSI from the UpgradedImage folder in the InstallShield IDE in direct edit mode, I've noticed that it removes the files that you're updating with the quickpatch from their original components, but I don't see that it removes ALL files from all Components from the entire original package. Am I missing something there? Actually, I don't think that would make sense. If that were the case, wouldn't the generated patch want to remove all those files that aren't part of the UpgradedImage as well?

Oh, one other question with this. After making the copy of the .msi package, I need to generate a new "Package" code GUID for the copy don't I?

Cary R wrote:
--When new files are added, each gets a subfeature and component associated with it. There's no strict requirement for doing it this way, which is why the "New" style quickpatches don't do this. As long as you're careful with file versioning, your files will get updated correctly.

In my case I'm only ever updating files that already exist in the original setup, never adding new files. As such, in my implementation, I don't plan to modify Features or Components at all. The existing components will just pick up the new versions of the files in my equivalent of the UpgradedImage folder. All I should have to do is update the MSI Table info (Version, Size, Language, Hash) as you mention in the next item. I should be okay with that shouldn't I?

Cary R wrote:
--New or updated files are the only files present in the uncompressed UpgradedImage folder. Although, you'll have to update their MSI Table information manually (mostly, Version, Size, Language, and the file hash).

I noticed that only the updated files are present in the uncompressed UpgradedImage folder, and that confused me. I was suprised it didn't cause any errors in the patch build process about files missing. IF, as you suggested in the first item above, QuickPatch removed ALL other files, I might understand how it wouldn't conflict, but as I said above, it doesn't seem to actually be removing ALL other files, only the ones being updated. Is there something special here with building the patch having all the other original files that AREN'T being updated missing, or is it a "it just works" type of thing and just accept that it works?

Cary R wrote:
Sorry for being unclear on this one. You'd modify the *.pcp file, and then hand it off to the Microsoft Patch API. Or, I believe the InstallShield Automation has the ability to build based off of a *.pcp file as well:

http://kb.flexerasoftware.com/doc/Helpnet/installshield12helplib/IHelpAutoBuildPCPFile.htm

Yeah, this is something I was wondering now that you mention it. I was wondering if InstallShield had their own customized patch building interface, or was just calling the standard Microsoft patch builder? I see the PatchWiz.dll in the IS2008\System directory, but I also see an IsPatchWiz.dll. And I DON'T see the standard Microsoft MSIMSP.exe file that's usually used to manually build a patch from the command line. So does InstallShield have it's own custom patch builder function, or is it just calling the standard Microsoft PatchWiz.dll behind the scenes? And if it's customized, do you know (and can you tell me if it's not company confidential) what's different in the IS customized patch builder?

Cary R wrote:
Thankfully, this is an easy one. You browse to the "UpgradedImage" folder, which is what's used to build the QuickPatch off of. A patch at its core is just the difference between 2 databases (in the form of 2 or more *.mst files) wrapped up in the *.msp as a container for the transforms.

The question was more about where in the InstallShield Patch Design view interface do I go to browse to the old QuickPatch images? But I think I figured it out. I would just add more "Previous Setup" items, one for the original release, and then one for each QuickPatch since then, right?



Okay, I have a new question about using InstallShield QuickPatches, in IS 2008. This ties to back to something I mentioned in my original post. For these "data" files, we have "test" versions that we use during a development cycle. So the base install contains the "production" versions of the files, and then I create a QuickPatch to apply on top of that to put the "test" versions in place. (Right now I am using InstallShield QuickPatch for this.) Again, the files in the "test" quickpatch are only replacing files that already exist in the base install. But because of the version check thing, every time we rebuild the main msi, we then have to rebuild the QuickPatch for it. I originally thought I could just reopen the old QuickPatch item and rebuild it. (The Original Setup Path would just already have the uncompressed image of the rebuilt main msi.) But when I try to rebuild it, it tells me that the package code of the main MSI has changed and it won't let me rebuild it. I see the package code for the original MSI is stored in the ISQuickPatchProperty table. Given that I know that the Components in the main msi have not changed for the files that are being replaced by the quickpatch, would I be safe to just copy & paste the new Package code from the rebuilt main msi into the ISQuickPatchProperty in the QuickPatch project and then let it rebuild? We'd never do that for a production patch, but for these "test" patches only during the development cycle I think we'd be okay to do that.

OH, and that reminds me, is there any way to either modify a QuickPatch project through automation, or can a QuickPatch .ism project file be saved in XML format (I don't see that option anywhere for that type of project so guessing not), so that I could update that Original MSI Package Code value through a script?

Thanks again!

[Cary_R]

Hi There,

For your remaining questions:

"After making the copy of the .msi package, I need to generate a new "Package" code GUID for the copy don't I?"

Yes.

"So does InstallShield have it's own custom patch builder function, or is it just calling the standard Microsoft PatchWiz.dll behind the scenes? And if it's customized, do you know (and can you tell me if it's not company confidential) what's different in the IS customized patch builder?"

InstallShield just calls PatchWiz.dll, but I can't say I know fundamentally if there's a difference between how we invoke the API and MsiMsp.exe. I've heard of the rare case where MsiMsp.exe does things slightly differently, but it's VERY rare.

"I would just add more "Previous Setup" items, one for the original release, and then one for each QuickPatch since then, right?"

Correct.

"Given that I know that the Components in the main msi have not changed for the files that are being replaced by the quickpatch, would I be safe to just copy & paste the new Package code from the rebuilt main msi into the ISQuickPatchProperty in the QuickPatch project and then let it rebuild? "

Safe-ish, anyways. I can't think of anything else that would cause breakage with this approach, but that doesn't mean there isn't something I've forgotten about or was unaware of. My recommendation would be to test thoroughly before you make this your new process.

" is there any way to either modify a QuickPatch project through automation, or can a QuickPatch .ism project file be saved in XML format (I don't see that option anywhere for that type of project so guessing not), so that I could update that Original MSI Package Code value through a script?"

There's not really an option to save as *.xml, however, you can use MSI automation to make the change to the *.ism file. In the Windows SDK it's 'wirunsql.vbs':

Execute SQL Statements
http://msdn.microsoft.com/en-us/library/aa368568(VS.85).aspx

[clhug42]

Fantastic!! Thanks again for all your help. A few more questions, a couple follow-ups and a couple new ones.

Cary R wrote:
There's not really an option to save as *.xml, however, you can use MSI automation to make the change to the *.ism file. In the Windows SDK it's 'wirunsql.vbs':

Execute SQL Statements
http://msdn.microsoft.com/en-us/library/aa368568(VS.85).aspx

I can use *MSI* automation on an .ism rather than an .msi? And it'll understand the format of the QuickPatch based .ism (which is not a standard Windows Installer thing is it?)?


One thing that wasn't addressed from my previous post, about the QuickPatch UpdatedImage folder containing only the updated files vs. all the files for the entire new image. Do you know if there's something special there that makes that work and not error out when the patch is built? Or does it just work and you don't know why? (You had mentioned that in the copied .msi, InstallShield removes all the original files, but I found that not to be true when opening the copied msi in InstallShield direct edit mode. It removes the original files that you're replacing via the QuickPatch, but not ALL other files.)


New question. This is really more confirming what I think is the case and just making sure I understand it. This specific question isn't so much about patching, just "updates" in general, but does lead to the next patch question below. I understand the basics of files and key files under Components, and having 1 file per component vs. having multiple files under a single component. Am I correct that, to be able to properly do a "small" or "minor" update (forget patches, just a normal update using the full msi package), a general statement would be that any file that might be updated by itself, independently of any other files, has to be in it's own component by itself? Otherwise it risks not being updated in a small or minor update if the key file of the component it is in is not updated. Correct?


Another new question, but follow-up from the above question about minor updates. I used Patch Design to build a normal patch between two versions. Normally this would have been a "small" or "minor" update if we used the full package to update. When I added the references to the previous version in the new version, and built the new version's full package, I got the warning that one of the files would not update in a minor update because the key file for that component didn't change. I understand that and do see why that happens. So then I went ahead and built the patch using the Patch Design view in the newer version. When I installed that patch on the older version, I was totally astonished to discover that the patch DID still update that file that a small or minor update would not have normally updated because of the key file not changing. So are there different update rules for a patch than for a small or minor update? Again, this patch was built using the Patch Design view, not QuickPatch. From QuickPatch I would understand it becuase of how QuickPatch creates the new subfeatures and components, but a "Patch Design" view patch doesn't do that does it? I was thinking a Patch Design view patch would be essentially the same as a standard basic Windows Installer patch.


Related to that, I had another file that was part of a component that used a linked directory to pull in a bunch of files. ONE of those files was updated. When building the full package of the updated version, I expected to get the same error about that file not being able to be updated on a minor update becuase it's key file not being updated. But I did NOT get that error on this file. In InstallShield 2008, does a component that pulls in files using a linked directory treat them as separate components at build time? I see that listed as a new feature in IS 2010. I thought IS 2008 would treat them as all being part of the same component and wouldn't update the one file in a minor update. Can you explain what's happening here?

Thanks again!

[Cary_R]

Well,

I can use *MSI* automation on an .ism rather than an .msi? And it'll understand the format of the QuickPatch based .ism (which is not a standard Windows Installer thing is it?)?

Sorry I wasn't clear on this; by default InstallShield stores project files in MSI Binary Database format. So we'll use different tables and such, but you just need to use Direct Editor to look up the tables, columns, etc.

One thing that wasn't addressed from my previous post, about the QuickPatch UpdatedImage folder containing only the updated files vs. all the files for the entire new image. Do you know if there's something special there that makes that work and not error out when the patch is built?

As far as I know the only thing special is that the Patch API sees files missing in the UpgradedImage folders as "No Changes Made" therefore it doesn't include any changes to them in the patch transform.

Regarding removing the files, I should clarify. The File Table records stay there (by keeping them it doesn't include any instructions in the patch transform to indicate they've changed. Removing them from the File table would include "Remove" instructions in the transform, and thus orphan all the files and leave them behind when uninstalling the product). What I'm getting at when I say that it "Removes the Files" is that it removes the actual files from the uncompressed image on the file system so that the Patch API has nothing to compare the previous files against, and automatically assumes they haven't been modified.

Am I correct that, to be able to properly do a "small" or "minor" update (forget patches, just a normal update using the full msi package), a general statement would be that any file that might be updated by itself, independently of any other files, has to be in it's own component by itself? Otherwise it risks not being updated in a small or minor update if the key file of the component it is in is not updated. Correct?

Mostly correct. In a case where you have no KeyPath, the folder is used as the keypath, which Windows Installer will then just assume that the component needs to be reinstalled and it'll look at each file individually based on file overwrite rules. In a Minor Upgrade you might be able to get away with this, but if you are trying to ensure that Autorepair catches these files if they have gone missing, you won't trigger the repair if you delete all the files under a component with no keypath (only if you remove the entire folder itself).

So are there different update rules for a patch than for a small or minor update?

No. The behavior you're seeing suggests that something else was going on. The keypath of the component probably changed in some meaningful way; check for entries in logfile referring to this file that start with "FileCopy" -- this will give you a justification as to why that particular file was overwritten. Remember, if it was a Versioned file (like a *.dll or *.exe, etc.) it will compare the version in the Patch's File table against the Version Resource of the file on the target system. And you have the ability to fake out the File Table record via manually setting it or using "Always Overwrite".

I see that listed as a new feature in IS 2010. I thought IS 2008 would treat them as all being part of the same component and wouldn't update the one file in a minor update. Can you explain what's happening here?

Generally, file linking creates a new component for each subfolder. Otherwise it picks a random file as the keypath. It's possible you "Won the Lottery" with the file you're updating.

Now, if you're doing Patching with the old style of Dynamic File Linking, I would say to take a step back and look at fixing that before going forward. The "Patch Optimization" setting can help make things work right, but odds are at some point you're going to have a case where a component doesn't match quite right because of a subfolder in a dynamic link, and nothing will be updated by your patch. (For an explanation, see: http://blogs.msdn.com/b/windows_installer_team/archive/2005/07/22/442599.aspx)

If you can't update to the "New" style of file linking (which I think was in InstallShield 2009) then you can start getting around this by creating 1 file link per folder, and having a "Dummy" *.txt File you mark as "Always Overwrite", or setting the version number to 1.0. This always makes the component reinstall during a patch/upgrade, and then looks at the rest of the files to see if they need to be updated.


Whew!

Hope this helps!

[clhug42]

Thanks again! "Whew" is right. Almost there...

Cary R wrote:
Mostly correct. In a case where you have no KeyPath, the folder is used as the keypath, which Windows Installer will then just assume that the component needs to be reinstalled and it'll look at each file individually based on file overwrite rules. In a Minor Upgrade you might be able to get away with this, but if you are trying to ensure that Autorepair catches these files if they have gone missing, you won't trigger the repair if you delete all the files under a component with no keypath (only if you remove the entire folder itself).

Thank you for clarifying that. That definitely helps understand better. I knew that not having a key file caused it to just use the folder, but then I thought on an update, if the folder existed it wouldn't bother to look at the files within it at all. Good to know that it does still look at the files on an update, but NOT for an Autorepair (I never even thought about a repair scenario).

Cary R wrote:

clhug42 wrote:
Another new question, but follow-up from the above question about minor updates. I used Patch Design to build a normal patch between two versions. Normally this would have been a "small" or "minor" update if we used the full package to update. When I added the references to the previous version in the new version, and built the new version's full package, I got the warning that one of the files would not update in a minor update because the key file for that component didn't change. I understand that and do see why that happens. So then I went ahead and built the patch using the Patch Design view in the newer version. When I installed that patch on the older version, I was totally astonished to discover that the patch DID still update that file that a small or minor update would not have normally updated because of the key file not changing. So are there different update rules for a patch than for a small or minor update? Again, this patch was built using the Patch Design view, not QuickPatch. From QuickPatch I would understand it becuase of how QuickPatch creates the new subfeatures and components, but a "Patch Design" view patch doesn't do that does it? I was thinking a Patch Design view patch would be essentially the same as a standard basic Windows Installer patch.

No. The behavior you're seeing suggests that something else was going on. The keypath of the component probably changed in some meaningful way; check for entries in logfile referring to this file that start with "FileCopy" -- this will give you a justification as to why that particular file was overwritten. Remember, if it was a Versioned file (like a *.dll or *.exe, etc.) it will compare the version in the Patch's File table against the Version Resource of the file on the target system. And you have the ability to fake out the File Table record via manually setting it or using "Always Overwrite".

Couple follow-ups here. I didn't have the file itself set to Always Overwrite, but I did have the patch design set to "include whole files". I'm not sure that would make a difference. Also I'm sure the keypath did not change. I copied, but made NO changes to the .ism file itself for the "new" version. All I did for the "new" version was that I replaced the files in the source location that the .ism pulled from and rebuilt the .msi to pick up the new files. I got the error that that file would not be updated in a minor update because InstallShield recognized then that the key had not changed. And the key for this component IS a versioned .exe file. I WAS wrong on one thing. I got this error happened when I build the new MSI, but it happens when I build the patch. Again, this is a Patch Design patch, not a QuickPatch.

So this is the error I get during the patch build.
ISDEV : error Val0004: The file 'direg.reg' in component 'DIAlways' is different from the file in the previous package, but the key file for this component did not change. As a result, the changed file will not get installed in an upgrade scenario. Place this file in its own new component.

When I install the patch and enable logging, this is what I see in the log file for the patch installation regarding the Component and the specific file (direg.reg) that is involved here:
MSI (s) (A0:50) [12:08:23:993]: Component: DIAlways; Installed: Local; Request: Local; Action: Local

MSI (s) (A0:50) [12:08:24:962]: File = direg.reg: Final State = Install

If I have it set to include whole files when I build the patch in Patch Design view, I see this entry in the log file when installing the patch:
MSI (s) (A0:50) [12:08:27:524]: File: C:\Program Files\Principal\MktgIllus\Disability\DiReg.reg; Overwrite; Won't patch; Existing file is unversioned and unmodified - hash doesn't match source file

If I let the patch build differenteral updates instead of whole files in Patch Design view, I see this entry in the log file when installing the patch:
MSI (s) (04:40) [12:23:01:325]: File: C:\Program Files\Principal\MktgIllus\Disability\DiReg.reg; Patch targets existing file.; Smart patch; Existing file is unversioned and unmodified - hash doesn't match source file


But bottom line is that it appears that the PATCH install IS indeed using different overwrite rules than a Minor Update would when looking at the files. Any further guesses on that?

Cary R wrote:

clhug42 wrote:
Related to that, I had another file that was part of a component that used a linked directory to pull in a bunch of files. ONE of those files was updated. When building the full package of the updated version, I expected to get the same error about that file not being able to be updated on a minor update becuase it's key file not being updated. But I did NOT get that error on this file. In InstallShield 2008, does a component that pulls in files using a linked directory treat them as separate components at build time? I see that listed as a new feature in IS 2010. I thought IS 2008 would treat them as all being part of the same component and wouldn't update the one file in a minor update. Can you explain what's happening here?

Generally, file linking creates a new component for each subfolder. Otherwise it picks a random file as the keypath. It's possible you "Won the Lottery" with the file you're updating.

Now, if you're doing Patching with the old style of Dynamic File Linking, I would say to take a step back and look at fixing that before going forward. The "Patch Optimization" setting can help make things work right, but odds are at some point you're going to have a case where a component doesn't match quite right because of a subfolder in a dynamic link, and nothing will be updated by your patch. (For an explanation, see: http://blogs.msdn.com/b/windows_installer_team/archive/2005/07/22/442599.aspx)

If you can't update to the "New" style of file linking (which I think was in InstallShield 2009) then you can start getting around this by creating 1 file link per folder, and having a "Dummy" *.txt File you mark as "Always Overwrite", or setting the version number to 1.0. This always makes the component reinstall during a patch/upgrade, and then looks at the rest of the files to see if they need to be updated.

There is only one folder, no subfolders, so that's not it. It's possible it picked that as the keypath. However, I opened the the two resulting MSI's in direct edit mode and it shows NO key file for that component.

Can you explain the difference between the "old" style and "new" style of Dynamic File Linking. Again, we are using IS 2008 and upgrading any time soon isn't an option. So is that the "old" style? Also, is that the URL you meant to include? It doesn't seem to make any mention of Dynamic File Linking nor patching or minor updates.

Also, what do you mean by "fixing" the "old" style of Dynamic File Linking? Do you just mean including each file directly instead of using Dynamic linking at all? Or is there something else?

The idea of the dummy .txt file might work, though I kind of hate to introduce files that aren't really needed.

I think this maybe ties back to the whole separate topic you mentioned above about how not having a key file makes it use the directory itself, and that with that, on a minor update Windows Installer WILL look at every file independently but on an auto-repair you have to delete the whole directory (not just contents) to get it replace the files on an auto-repair. This is based on 2 things. As I said just above, I opened the two MSI's that I was building a patch between and discovered that it had NO key file assigned in that component in either MSI (contrary to the statement that the system would just randomly pick one of the linked files as a key). So it DID look at every file within that component when building the patch and did not genereate the error about the key file not being updated. Similarly, just as a counter-test, I went back up to the component that I got the error with mentioned above with the direg.reg file and Unmarked the key file in that component so it did NOT have a key either (and these are not dynamically linked files). After I rebuild the new MSI again, and then when rebuilding the patch, I did NOT get the error about the direg.reg file not being able to be updated because of the key file not being updated. So it's just the fact that there is NO key file in the component that causes me not to get the error for this other file in the component that uses the dynamic linking.

Thanks a BUNCH one more time!!

[clhug42]

Still have the few remaining questions from my previous post in this thread, but got a new one too.

I don't have any automation code done but using the information from this thread so far I've been working on just manually creating my own patches so I understand what functions I have to code in automation.

These are the basic manual steps I'm using to manually create the patch:

[LIST=1]

Have an uncompressed version of the original MSI.

Copy MSI file from the UNCOMPRESSED instance of the old version.

Put any new files in the same uncompressed subdirectory structure under wherever the copy of the MSI was made to.

Open copied MSI file in InstallShield IDE.

Under General Info, Summary Information Stream, Package Code: Generate a new GUID.

Using Direct Editor, modify the FileSize and Version, and file hash if unversioned file.

Set up the PCP file and use MSIMSP.EXE go generate the patch.

As I mentioned in an earlier reply in this thread, all I'm doing in the patch is replacing a file that already exists in the original MSI. In this test case I'm doing, the particular file I'm replacing is an UNversioned file (it's a Microsoft Access .mdb file). In the copied MSI, I am NOT adding any new Subfeatures or Components like QuickPatch does. Just modifying the Files and MsiFileHash tables to reflect the data for the new version of the file but still under the same Component as the original MSI.

The patch builds successfully, and basically even installs fine. BUT, the Date/Time stamp on the updated file on the destination file after I install the patch is the date and time that the patch was built rather than the date on the source file. The file itself is correct, it's just that the date/time stamp is goofy.

Any ideas?

[clhug42]

I don't mean to be a pest but I'm hoping Cary R is still out there, or for anyone, to answer my previous two posts in this thread again! Been a GREAT help so far and I'm almost there, but have a few remaining things.

Thank you!