Upgrading an install

[u863583]

Setup Factory for Windows does a great job in simplifying the MSI install creation process. I have been using Setup Factory 7 as well as true Updater2, among other Indigo Rose products. All first rate.

Although creating a setup with SUFWIN seems relatively simple, I am really struggling with how I maintain the install once released. I do not fully understand the upgrade process, and how the GUID's are to be maintained.

Using SF7 and True updater, I never had issues with patching the update, and maintining updates once the install was released. But with SUFWin, I am really concerned about releasing installs, because I do not have a good understanding of how I can maintain the install once released. The upgrade process appears to require a lot of manual effort for MSI installs. Am, I missing something? Is there a simple method of patching and upgrading products using Setup factory for Windows?

At this point, I would be happy to do some type of silent uninstall, and doing a full reinstall of the patched/latest version. I know this is something that has to be right the first time I release an install, because if I mess up the upgrade path, then I will have many unhappy and frustrated customers. Is any tutorial in the works to explain the correct method to patch an MSI install using SUFWin. I have read the help file, and am just not fully understanding exactly what the correct process is. Any additional insight on this process would be most appreciated.

thanks,

M.

[eric_darling]

Sounds to me like you're explaining the reason that Visual Patch was made.
Visual Patch rocks. I have owned it for a year or so, and I can't imagine life without it now. It makes updating software a cinch.

[Brett]

u863583,

That kind of information is certainly something that we will be producing in the future. To get you started, here is my reccomendation:

Assuming that you are doing Minor updates, simply update the Product Version (Product tab of Project Settings) each time you do a new release. A minor update is characterized by the following:

- The product itself has not changed - it is a service release or bug fix type installation.
- You are updating files that you are installing
- You may be adding new files to the setup
- You are not removing files from the installation (especially not from components that are still in the installer)

Then your best bet would be to generate the installer with the bootstrap wrapper. The boot strapper will take care of detecting if the version it is installing is older, the same, or newer than the version of the product on the system. So, just have TrueUpdate determine if a new version is available, if needed, download the new setup.exe file and run it.

It should be as simple as that.

If you are doing more dramatic changes, then you will probably need to change your product code and provide upgrade codes to make the product remove the old version and then install the new one. The help topic "Product" in the help file goes into a bit more detail about upgrade codes and product codes.

[u863583]

Thanks Eric,

Appreciate your response. I do not believe that Visual Patch is the solution in this case. It could still be very helpful, but MSI has very strict rules about how the patch file is created. I do not have any problems with delivering the patch. Use TrueUpdater2 and will likely continue to do so with SUFWIN. However, once the original MSI install is out, I am not sure how to create patches that adhear to the MSI requirements.

For example I am reading that many MSI patches are delivered as MSP files. It does not appear the MSP support currently exists with SUFWIN. This can cause me significant issues, since if I release an install with SUFWIN, I am not certain I will be able to maintain it currently. Short of having customers do a full uninstall and reinstall of the latest version, which is not really desirable either short term of long term.

I realize I have a lot to learn about MSI still, but it does appear that creating patches with SUFWIN is still not quite there yet. Hopefully it is just my ignorance currently and SUFWIN already fully supports patching of the MSI's. I'll keep looking.

SUFWIN is first MSI installer I actually like to make MSI's with. I have used InstallShield 11, and hate it. But it has a nice wizard wizard used to create patch files. This does not appear to yet exist with SUFWIN. If patching does exist with SUFWIN, then hopefully it will evolve to be as easy as Indigo Rose has made creating the original MSI file.

Perhaps I am missing something, but I am concerend about releasing a comercial build with SUFWIN, if I am not certain I can maintain it correctly following MSI patching rules. (Which I don't at this time really understand yet).


thanks again for your post. I'm still very much trying to get up on the learning curve with making high quality MSI installs , but I believe with SUFWIN, I just may get there.

Best Regards,

M.

[u863583]

Brett,

Thank you, thank you, thank you.

You make it sound trivial. I'll look it over and give it a try. Makes me feel much better now.

Regards,

M.

[u863583]

Works great! This is very nice.

thanks

Manny

[Lorne]

It's actually possible to make .msp files right now if you don't mind editing XML. Creating patches with MSI is a pretty involved process, though.

Note that although MSI supports binary differencing, its differencing engine is horribly slow -- it can take 10 minutes to create a difference for a 6 MB file, which is just absurd. (Our DeltaMAX engine can do the same file in under a second.) So generally I would recommend using the WholeFilesOnly option when producing MSP files unless all of your files are very small.

Example of Creating an MSI patch using Setup Factory for Windows Installer
-------------------------------------------------------------------------

1. Create the new version .msi project

1.1. Put your new version source files in a separate folder.
1.2. Open the SFWI project for the old version. Starting from the existing project ensures that the product and component GUIDs remain the same. If you start a new project from scratch, you'll need to manually edit all the GUIDs to match.
1.3. Save it with a new name.
1.4. Update the version number to match the new version.
1.5. Change the output folder or the output name (don't overwrite the old version).
1.5. Change the source locations for the files to point to the new source location.
1.6. Add any new files to the project that didn't exist in the old version. (You can add files without any extra steps.)
1.7. IMPORTANT - if any files in the old version are not in the new version, you must:

1.7.1. Add a RemoveFile action to that file's component to remove the file. The remove file action must be in the same component as the file that will be removed.
1.7.2. Remove the file from the component in SFWI, leaving only the RemoveFile action.
1.7.3. Consider making the component the key path? I didn't, I just let the build make a registry value key path for it. I'm not sure what effect changing the key path between versions like this will have, I seem to recall that being discouraged. (It might be wise to mark the component's directory as the key path right from the start, i.e. beginning in the original version.)

NOTE: the ProductCode and UpgradeCode should NOT change -- don't change them.

2. Build the new .msi file.

3. Create an admin installation of the old version.

3.1. Use msiexec /a to create an uncompressed image of the old .msi file. This will represent the "RTM" ("Released To Manufacturer") version. Example:

msixec /a foo_100.msi TARGETDIR=C:\temp\patchdir\foo\rtm

3.2. Use msiexec /a to create an uncompressed image of the new .msi file. This will represent the "latest" version. Example:

msixec /a foo_101.msi TARGETDIR=C:\temp\patchdir\foo\latest

4. Create a .wxs file describing the patch.

4.1. See foo_patch.wxs for an example.
4.2. Set a unique GUID for PatchCreation @Id.
4.3. Set PatchCreation @OutputPath to match the desired patch (.msp) file name. (Not sure if this is necessary but I've always done it so far.)
4.4. Set PatchCreation @WholeFilesOnly to 'yes' to turn off binary diffing. Binary diffing gets really slow if there are any files above 5 MB.
4.5. Set the attributes in the PatchInformation element. (It seems if the Description and Comments fields are omitted, msimsp will fail.)
4.6. Set the attributes in the PatchMetadata element. I've had equal success using "Hotfix" or "Update" for @Classification. (Hotfix is supposedly for a patch where the version number doesn't change.)
4.7. Set a unique name, 8 characters or less, for Family @Name. Not sure if it's supposed to be unique per product, or what. (8 characters! Sheesh.) See http://wix.sourceforge.net/manual-wi...h_building.htm.
4.8. Set Family @DiskId to something appropriate; all the examples I've found used 2.
4.9. Set Family @MediaSrcProp. See http://wix.sourceforge.net/manual-wi...h_building.htm.
4.10. Set Family @SequenceStart. See http://wix.sourceforge.net/manual-wi...h_building.htm.
4.11. Set the UpgradeImage element to describe the new version. Make sure you use the correct file in @SourceFile.
4.12. Set the TargetImage element to describe the old version.
4.13. Supposedly you can have multiple Family elements and only patch specific features by name, but I haven't tried it yet.

5. Compile the .wxs file using candle. Example:

candle foo_patch.wxs

6. Link the .wixobj file into a .pcp file using light. Example:

light foo_patch.wixobj -out foo_patch.pcp

7. Build the actual patch (.msp) file using msimsp.exe. Example:

"C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Samples\SysMgmt\Msi\Patching\msimsp" -s foo_patch.pcp -p foo_patch.msp -l foo_patch.log

Note: Instead of downloading the whole SDK, you can run the following line, which downloads and installs the basic tools instead....

msiexec /i http://download.microsoft.com/download/F/A/D/FAD9EFDE-8627-4E7A-8812-C351BA099151/PSDK-x86.msi /qr ADDLOCAL=SDK_MSI_BIN,SDK_MSI_SMP

Tools are going to be installed in the following path:

C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Samples\SysMgmt\Msi\Patching

8. To apply the patch, it seems you can either use msiexec /upgrade or msiexec /p (I've tried both and they both seem to work). Example:

msiexec /p foo_patch.msp REINSTALL=ALL /L*v foo_patch.log

NOTES:

• the .msi name can change between the old and new version, so long as the correct name is referenced in the patch.wxs file
• Microsoft says you need to change the product code if you remove any components from a feature. The very sneaky workaround to make removing files possible is to keep the component in the project, and replace the file inside it with a RemoveFile action.

[u863583]

That does'nt look like much fun!

Hope future versions of the product work at simplifying this.

Thanks,

Manny

[Lorne]

Originally Posted by u863583

That does'nt look like much fun!

None of the MSI stuff is!

Hope future versions of the product work at simplifying this.

Yes, we plan to offer a simple way to create patches. My notes above are not really meant as a tutorial -- I just wanted to share the details in case anyone wants to build MSP patches right now.

(Since SFWI uses WiX to build the MSI files, anything that is supported in WiX is also supported in SFWI, even if we haven't implemented a GUI for it yet.)