Software Deployment

Windows File Protection
Purpose

Windows® File Protection (WFP) prevents the replacement of essential system files installed as part of Windows. Applications should not overwrite these files because they are used by the system and other applications. Protecting these files prevents application and operating system failures.


GUID stands for globally unique identifier. It is a data type comprised of a text string that represents a Class identifier (ID).

The purpose of a GUID is to provide a unique identifying string that differentiates products, packages, components, features, upgrades, patches, and so on. By reading GUIDs, Windows Installer can determine what is installed on a destination computer and take appropriate action.

1) Too many differences to list. There are two families of Windows, the "Windows on DOS" faimily and "Windows OS" family. Each version of a family is built on the previous family version so it will have some similarities & enhancements. The "Windows On DOS" family consisted of 3.x, 95, 98, and ME. This branch of the tree is now thankfully dead. The "Windows OS" family is NT 3.51, NT 4.0, Win2000, WinXP, Win2003 and future Windows releases (Until this branch becomes

2) Windows File Protection keeps you from screwing up your OS. The only disadvantage is that you have to do things correctly now, and don't trample your OS files when you install stuff.

3) Custom Actions allow you to do stuff that can't be processed within MSI's standard tables.

4) It's a randomly generated identification number that is so random it is unlikely that duplicate GUIDs will ever be generated within our lifetimes. (Plus what bheers said)

5) Product/Featrue/Comonent forms a tree. If a self repair is triggered, it will fix that point of the tree and everything below it. Manually triggered repairs are done at the root.

6) Wise & Installshield are almost at a tie for best. Wise has an edge in corporate repackaging / collaboration. InstallShield has an edge on the development side. They're still pretty close though, so personal preference also plays a hand.

ORIGINAL: VikingLoki


5) Product/Featrue/Comonent forms a tree. If a self repair is triggered, it will fix that point of the tree and everything below it. Manually triggered repairs are done at the root.


Everything BELOW it? Are you sure that is true?

I double checked the docs, I was somewhat correct.

Self-repair is only performed on the feature level. If a component is corrupt/missing the self-repair will repair the entire feature, but not the entire application. If it's a setup-capture MSI (or poorly authored MSI) everything will be lumped into a single feature, so it can seem like the entire app gets repaired but that isn't really the case. This is why it's a good idea to lump all user profile / HKCU stuff into a separate feature. That way, if a new user logs on only the user's stuff is repaired (which will be necessary) and not the entire application (which probably isn't necessary). There may be other situations where you would want to group things into separate features as well. Just keep in mind that self-repairs are limited to features and do what's right for your situation.

So... yes, self-repair fixes everything below it. But only from the feature level. A manually initiated repair fixes all features.

ORIGINAL: VikingLoki

I double checked the docs, I was somewhat correct.

Self-repair is only performed on the feature level. If a component is corrupt/missing the self-repair will repair the entire feature, but not the entire application. If it's a setup-capture MSI (or poorly authored MSI) everything will be lumped into a single feature, so it can seem like the entire app gets repaired but that isn't really the case. This is why it's a good idea to lump all user profile / HKCU stuff into a separate feature. That way, if a new user logs on only the user's stuff is repaired (which will be necessary) and not the entire application (which probably isn't necessary). There may be other situations where you would want to group things into separate features as well. Just keep in mind that self-repairs are limited to features and do what's right for your situation.

So... yes, self-repair fixes everything below it. But only from the feature level. A manually initiated repair fixes all features.


That's closer to my understanding.

I thought also, if a self repair is triggered from a bad keypath in a sub feature, as well as that whole sub feature being repaired, the parent feature keypaths are checked. However, if a keypath in the parent is missing, the repair is done at the component level. However, I cannot now find any formal docuemntation to this effect :(

I cannot now find any formal docuemntation to this effect :(

I can't either. I did see it once though, it did exist at some point.

Found it! It's a PDF from who the heck knows where. There is a link to it in Wise KB article 1389 (http://www.wise.com/kbarticle.aspx?articleno=1389

Here it is, mystery info from the mystery source: http://209.104.132.210/filelib/KB/WindowsInstallerRepair.pdf