Software Deployment

I'll be interested to know everyone elses opionions on how they go about this, but I would:

Put the files that get updated in a sub feature on there own with no entry points. You can make sure there are no keypaths for the components in that feature too if you want, but with no entry points you should be ok.

Graham

It's unfortunate that the application does this, since MSI is supposed to be managing these files.

It's also very strange because:

1) A change in a file keypath should not trigger a repair (only a missing file keypath).

2) A later file should not be overwritten by an older one.

You can check which component is broken and triggering the repair using the event viewer.

As GB1 rightly said, it may be safer to move the affected component(s) to another feature. Although, I'd consider moving them to an independent top level feature.

Not only a missing file keypath can trigger a repair. Different versioning, modifydates or languagecodes can also trigger a repair. If you have a "d" in your REINSTALLMODE property the file will be replaced when differen or missing.

We seem to keep having this age-old debate over and over again.

Unfortunately, nobody has ever been able to produce a single shred of evidence that the above statement is true. Until someone does, I will continue to maintain that only "missing" file keypaths trigger repairs.

Here's a link to the last debate we had about this:

http://itninja.com/question/faulttree-10546&mpage=1&key=ᚑ

And what makes you think his REINSTALLMODE property might have a "d" in it during a self repair, when the default is "pocmus"? Don't you think he'd know if he'd gone to the trouble of changing it?

I have had to do this for a few in house applications.

I just asked the files that would need to be updated and moved them to a separate top feature. Then I removed all the Key paths for each component. You should also make sure there are no Com,typlib, AppID entries for any DLL, OCX, and other files that may need to be updated. If the files need to be registered you will want to use the Selfreg Table.

If you are removing the key path for the application EXE file, you will not be able to make it an advertised shortcut. You will need to point it directly to the EXE file.

If you do file hashing, I would also avoid creating hashes for any of the files that are updated.

You can also edit the MSI property table and set the REINSTALLMODE = pmus

This should allow the MSI to not trigger a repair on those files or reinstall them if a repair is done.

However, WiseUser is correct is I do not think it should keep repairing like that. Would your application update a registry entry that is installed as a key path in your msi?

Those are file versioning rules which apply once an upgrade is underway. What I've been talking about is what will actually "trigger" the repair process when an entry point (such as a shortcut) is invoked.

If you know a way of changing the default "REINSTALLMODE" value for automatic "self repairs" that occur when a broken component is found, I'd be interested to know how. TomB mentionned that it is possible to hard-code the "REINSTALLMODE" property within the property table of the MSI, but I'm pretty sure that won't affect "automatic" self repairs.

I have looked in the past and just now, and while I have been unable to find any documentation that states precisely that the REINSTALLMODE property is used when an MSI is repaired, I have also not found anything that says it is not.

If you review the MSI documentation the repair and reinstall sound as if they same are the same process, in which I believe they are.


"Resiliency is the ability of an application to recover gracefully from situations in which a vital component is missing, or has been replaced by an incompatible version. By authoring an installation package and using the Installer Functions, developers can use the Windows® Installer to produce resilient applications capable of recovering from such situations."
...
...
...
Use the installer to reinstall damaged shortcuts, registry entries, and other components without having to rerun setup.


If you look at the Windows Installer Functions you see the MsiReinstallProduct and MsiReinstallFeature, but no "repair".

So if the repair uses the reinstall functions then would it not make sense that it would use the REINSTALLMODE property?

A little more info:
MsiReinstallProduct = Reinstalls or repairs an installation.
MsiReinstallFeature = Validates or repairs features.

Thanks for the feedback ILikeBananas. I'm assuming that like me you've actually tried the "REINSTALLMODE" thing?

Yes TomB, a repair is nothing more than a reinstall. And of course the "REINSTALLMODE" property is used during a reinstall. Nobody has ever suggested anything different - certainly not me. What I'm discussing is what event can actually cause this repair or reinstall to occur in the first place (automatically).

Here's how to observe what I'm talking about:

1) Create a basic MSI with with a single feature, single component, single executable file (keypath), and a shortcut to the executable.

2) Hardcode the "REINSTALLMODE" property to something other than "pocmus".

3) Install the newly created MSI.

4) Switch verbose logging policy on:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Logging"="icewarmupv"

5) Delete your executable file (keypath) and then invoke your shortcut in order to trigger a self repair.

6) Check the value of the "REINSTALLMODE" property within the log file (in %Temp%) - you should find that it's not the value that you hardcoded.

However, if you now ran "Msiexec /i YourPackage.msi REINSTALL=ALL /qb" you most probably would find your hardcoded value of the "REINSTALLMODE" property in the log file.

I see what you are talking about. Sure enough the log has the the property REINSTALLMODE=pocmus, regardless of what is in the REINSTALLMODE property of the MSI.

Sorry for the confusion, I never noticed that in the log.

I would be interested if anyone finds out where this comes from or if it can be changed at all.

How do you hardcode the REINSTALLMODE? I cannot find the property anywhere or even in the manual.

Which manual are you using? This is the one most people tend to use:

http://msdn.microsoft.com/library/en-us/msi/setup/windows_installer_start_page.asp

The direct link you wantis here:

http://msdn.microsoft.com/library/en-us/msi/setup/reinstallmode.asp

If it's not in your Property table, then it's not hardcoded.

I was looking at the same pages, but from the installed MSDN subscription.

So if REINSTALLMODE is not listed in the file's property table then I don't have a REINSTALLMODE feature?

I need to configure the installer project to install / repair files even if they are missing or a newer one is installed.

REINSTALLMODE is like any Public Property. You can specify it on a command line or you can add the Property to the Property table and add your specific value to override the default setting. The default for REINSTALLMODE is "omus", so if you don't specify it you still have a REINSTALLMODE.

For what you would like to accomplish you might want to look at the file versioning rules for the installer.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/file_versioning_rules.asp

Thank you TomB & WiseUser for your links. However, I have read the MSDN and their instructions are for people how already know how to do this; I need instructions for Dummies.

Where do I find the Public Property list? How do I add a property to the Public Properties list?

OK. Here's the dummy version.[;)]

Command line options for "Msiexec.exe" are here:

http://msdn.microsoft.com/library/en-us/msi/setup/command_line_options.asp

Example:

Msiexec.exe /i mypackage.msi REINSTALL=ALL REINSTALLMODE=omus /qb

"omus" is the default. Check the SDK for other options.

Orca is an MSI database editor which is part of the Windows Installer SDK which can be downloaded from Microsoft. This DB editor will allow you to view, edit and add new properties in the Property table of any MSI.

I don't think I explain it any more basically than this?

If you still don't understand, I suggest that you explain in detail what you need to do.

Thanks, but I cannot use the command line parameters. The settings must be hardcoded in the package, as I was intested in - in my post a couple lines up. The people installing the application are more dummy then I am and they can get the command line wrong.

[&:]

Like I said previously, I think you have to be more specific about what you're trying to achieve.[;)]

We can point you towards the relevant documentation, but if you want help applying the theory to your particular scenario, I think we need to know what that scenario is?

I am packaging a major release. If there are any patches released afterwords that mess up the system I want to make sure the original major release will overwrite the new or corrupt files. Just like in Windows 2000, running the CD installation will overwrite any new and corrupt files so you have a vanila system again.

I probably should also mention that I am using Microsoft .NET Setup and Deployments project to create the package.

[8|]

Amccombs how are you planning on releasing the patches. I am guessing that this is an inhouse developed applicaiton and that you would also be createing the patches, is this correct?

How are you planning on deploying any patches? Would you use MSP files?
If so I would suggest that when you create the patches (MSP files) you look into using the MSI 3.0 patches because they have the ability to be uninstalled. This would allow for the user to uninstall the patch and to then repair the origional MSI if needed if a patch where to cause any issues with the system.

This would require that your users have at least Windows XP SP 2 or your install would need to install the 3.0 redistrib file.

This however is something that would require some bit of research on your part.
Most if not all documentation can be found on the MSI SDK link that WiseUser has provided above, but here is a link to the patching:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/patching.asp

ORIGINAL: amccombs

I am packaging a major release. If there are any patches released afterwords that mess up the system I want to make sure the original major release will overwrite the new or corrupt files. Just like in Windows 2000, running the CD installation will overwrite any new and corrupt files so you have a vanila system again.

I probably should also mention that I am using Microsoft .NET Setup and Deployments project to create the package.

[8|]

look into

Are these statements correct?

1) You want to restore the original file version even if a newer one has been installed (by a third party application or patch)?

2) You want the repair to occur automatically, without you having to initiate it with an "msiexec" command line (or from within your application)?

TomB:
I am not sure how I plan to release any patches if needed. But during my experiments, uninstalling a patch deletes the file and does not restore the original file. I don't know what version MSI that MS .NET makes. I think the target machines will have Windows 2003 Server.

WiseUser:
1) Yes I want to restore or replace the file version even if a newer one has been installed, there is no third party applications, all these files are my own.

2) I don't need them to repair automatically, and I probably don't want that feature either.

Slowly a picture is emerging...

I'm startnig to agree with TomB. The functionality you're looking for may be "removeable patches"?

If you're simply trying to upgrade your application on a regular basis whilst maintaining the ability to roll back to the previous version without a complete remove/reinstall, then follow TomB's advice.

Although the version of your MSI is important, the version of the installer engine on the client machines is MORE important.

If the file is has the same name and the patch has a file with a newer version an uninstall should remove the file. However, at that point you should still be able to repair the original install after uninstalling the patch and the original files will be reinstalled. Depending on if you have the key paths setup correctly then when you launch the application for the first time after the removal of the patch the application should do a self repair.

If you do not wish to utilize the new patching features in the MSI 3.0, then you can try to alter the file versions in the MSI tables directly.

For example, if your file has a file version of 4.5.6.7. You can edit the MSI in ORCA and go to the File table and in the Version column change the version number to 99.99.99.99. So long as the file is present a self repair will not take place (as discussed previously in this thread). If for some reason a file with a newer version overwrites your install file, you can manually do a repair either through the command line or add\remove programs and then your file will be reinstalled (so long as the file version is not greater than 99.99.99.99).

You can also do this for non versioned files, however you will want to put a language ID such as 1033 to pass validation.

However, a danger is if you released a patch that DID work and you wanted to keep it and a self repair is launched for what ever reason, those files will also be overwritten.

Not really, I don't think I want removable patches, that's much too complicated which I have proven to be.

No more KISS days huh? [:(]

Quote from TomB's link
Note It is not possible to eliminate all circumstances when the application of a patch may require access to the original installation source.

That's not acceptable.

I remember tring to uninstall somthing and I did not have the msi that it can with. It was a pain to uninstall it.

ORIGINAL: amccombs

No more KISS days huh? [:(]



I don't even know you!

You're not demanding at all!

With VERY careful planning, you can almost avoid the original source being required, but it's not simple.

WiseUser:
Your a funny guy/girl.

Even the crippled Microsoft InstallShield had a ALWAYSOVERWRITE setting. Imagine all the work I have to do to get a work-around for that missing feature. Then for my next work-around is how to execute a newly installed exe.