This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Confused on Update/Release/Patch
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 16, 2009
11:02 AM
Confused on Update/Release/Patch
I finally got my basic install to work, and I'm trying to understand the best way to release updates and new versions.
My Basic MSI Project is pretty simple, just one feature with a dozen files copied to the install directory. Right now I'm at version 1.0.0. Lets say I fix some bugs and one file needs to be updated, and I release this as 1.0.1.
I'm not sure how to do this inside of Install Shield. I've been reading the help file but I don't see exactly how to push one updated file into an update. Anyone have some tips? Thanks, KB
My Basic MSI Project is pretty simple, just one feature with a dozen files copied to the install directory. Right now I'm at version 1.0.0. Lets say I fix some bugs and one file needs to be updated, and I release this as 1.0.1.
I'm not sure how to do this inside of Install Shield. I've been reading the help file but I don't see exactly how to push one updated file into an update. Anyone have some tips? Thanks, KB
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 19, 2009
10:12 AM
KB -
after bashing my brains against all the white papers, documents & forum posts, I finally had to spend time experimenting. There are some basic steps, which, incredibly, I haven't found spelled out simply like this *anywhere*. They are:
To do a minor update:
1) make a copy of your project file into another directory. This will be your "upgrade" project
2) change the package code and product version of this upgrade project
3) go into the media > upgrades node. on the right side, right click and chose "add minor upgrade item." For that item, on the right, choose the original msi as the one you are targetting to upgrade.
4) make the changes in the new project file, e.g., replace the files you want replaced
5) Chose the patch design view. on the right, rt-click and chose "add new patch configuration." it will create a "latest" and "previous" subnodes. point the 'previous' node to the one you are targeting for the patch. The "latest" will automatically point to the new project file.
6) go to the Release view, select the release node, set Compression to Off on the Build tab. On the Setup tab, chose to build Setup.exe. Now build your uncompressed project
7) if you haven't, you will need to build your original msi as uncompressed
You are essentially doing what feels like a "diff" between the previous msi and the upgrade msi. Once you have both, you can then go into the Patch view and do a Build on your patch. It will create a patch with just the necessary differences between the two, and give you a Setup.exe.
I hope this helps someone else out there. I certainly was extremely frustrated at the documentation surrounding upgrades and patches. They make it sound like rocket science. For many of us, doing builds is just a tiny part of our jobs; the docs seem to be written for people who do this full time. I don't have the luxury of sitting back and spending days with this stuff.
I'm also discouraged that from what I've read, I can't automate patch builds with the command line tool. Again, I need to automate all this and put it on our build machine, I can't waste time with the IDE.
Mark
after bashing my brains against all the white papers, documents & forum posts, I finally had to spend time experimenting. There are some basic steps, which, incredibly, I haven't found spelled out simply like this *anywhere*. They are:
To do a minor update:
1) make a copy of your project file into another directory. This will be your "upgrade" project
2) change the package code and product version of this upgrade project
3) go into the media > upgrades node. on the right side, right click and chose "add minor upgrade item." For that item, on the right, choose the original msi as the one you are targetting to upgrade.
4) make the changes in the new project file, e.g., replace the files you want replaced
5) Chose the patch design view. on the right, rt-click and chose "add new patch configuration." it will create a "latest" and "previous" subnodes. point the 'previous' node to the one you are targeting for the patch. The "latest" will automatically point to the new project file.
6) go to the Release view, select the release node, set Compression to Off on the Build tab. On the Setup tab, chose to build Setup.exe. Now build your uncompressed project
7) if you haven't, you will need to build your original msi as uncompressed
You are essentially doing what feels like a "diff" between the previous msi and the upgrade msi. Once you have both, you can then go into the Patch view and do a Build on your patch. It will create a patch with just the necessary differences between the two, and give you a Setup.exe.
I hope this helps someone else out there. I certainly was extremely frustrated at the documentation surrounding upgrades and patches. They make it sound like rocket science. For many of us, doing builds is just a tiny part of our jobs; the docs seem to be written for people who do this full time. I don't have the luxury of sitting back and spending days with this stuff.
I'm also discouraged that from what I've read, I can't automate patch builds with the command line tool. Again, I need to automate all this and put it on our build machine, I can't waste time with the IDE.
Mark
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 19, 2009
02:33 PM
Mark, thanks for confirming what I was thinking!
It never states that you have to start a new project to be your upgrade project, but that is what I was leaning toward after reading for a few hours today. At least there is dynamic file linking to make this easier!
I'm starting to understand the process now, I'll post more if I get lost.
It never states that you have to start a new project to be your upgrade project, but that is what I was leaning toward after reading for a few hours today. At least there is dynamic file linking to make this easier!
I'm starting to understand the process now, I'll post more if I get lost.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 19, 2009
02:42 PM
(Regarding a previous comment, I don't know when it was introduced, but the command-line build tool ISCmdBld supports a -patch_config switch for at least building a patch. The InstallShield Automation interface also supports a BuildPatchConfiguration method on the ISWiProject object, which should do the same thing.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 19, 2009
03:47 PM
Thanks Robert - great to know patches can be done on the command line.
Mark
Mark
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 08, 2010
12:06 PM
Thanks mlerch. Good post.
Since moving to Installshield 2010, I'm flabbergasted by the lack of documentation on the Flexera websites regarding basic functionality such as patching, merge modules, upgrading. Take merge modules for instance. The Visual Studio 2008 runtime merge module only becomes functional after the install is completed. But........
What if a newly installed service depends on Visual Studio 2008 runtime merge module. This is what happened to us recently. When you ask for help on this topic on the Flexera community website, any answer from Installshield engineers usually is at best half baked. Blame Microsoft is the usual answer. Installshield should be kicking Microsofts a*se on behalf of their customers.
The merge module is clickable in the setup, but cannot be used during the install by any components being installed. At first I presumed they were joking. But no.
Since moving to Installshield 2010, I'm flabbergasted by the lack of documentation on the Flexera websites regarding basic functionality such as patching, merge modules, upgrading. Take merge modules for instance. The Visual Studio 2008 runtime merge module only becomes functional after the install is completed. But........
What if a newly installed service depends on Visual Studio 2008 runtime merge module. This is what happened to us recently. When you ask for help on this topic on the Flexera community website, any answer from Installshield engineers usually is at best half baked. Blame Microsoft is the usual answer. Installshield should be kicking Microsofts a*se on behalf of their customers.
The merge module is clickable in the setup, but cannot be used during the install by any components being installed. At first I presumed they were joking. But no.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 18, 2010
10:42 AM
While I know one can accomplish it this way, I really want to know if this is the recommended way or intended way that Flexera has designed the product. This seems counterintuitive to what I would expect this level of product.
You are definitely correct in there being very little documentation in the way of correct or best way to manage a product with releases, upgrades patches etc. Most of us cannot afford the training (both in time and money) in using the the Installshield product and would prefer comprehensive documentation on its use.
Could someone representing Flexera speak to the proper way to accomplish what the op wanted to do?
Thanks
You are definitely correct in there being very little documentation in the way of correct or best way to manage a product with releases, upgrades patches etc. Most of us cannot afford the training (both in time and money) in using the the Installshield product and would prefer comprehensive documentation on its use.
Could someone representing Flexera speak to the proper way to accomplish what the op wanted to do?
Thanks
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 18, 2010
04:12 PM
mlerch wrote:
KB -
after bashing my brains against all the white papers, documents & forum posts, I finally had to spend time experimenting. There are some basic steps, which, incredibly, I haven't found spelled out simply like this *anywhere*. They are:
To do a minor update:
1) make a copy of your project file into another directory. This will be your "upgrade" project
2) change the package code and product version of this upgrade project
3) go into the media > upgrades node. on the right side, right click and chose "add minor upgrade item." For that item, on the right, choose the original msi as the one you are targetting to upgrade.
4) make the changes in the new project file, e.g., replace the files you want replaced
5) Chose the patch design view. on the right, rt-click and chose "add new patch configuration." it will create a "latest" and "previous" subnodes. point the 'previous' node to the one you are targeting for the patch. The "latest" will automatically point to the new project file.
6) go to the Release view, select the release node, set Compression to Off on the Build tab. On the Setup tab, chose to build Setup.exe. Now build your uncompressed project
7) if you haven't, you will need to build your original msi as uncompressed
You are essentially doing what feels like a "diff" between the previous msi and the upgrade msi. Once you have both, you can then go into the Patch view and do a Build on your patch. It will create a patch with just the necessary differences between the two, and give you a Setup.exe.
I hope this helps someone else out there. I certainly was extremely frustrated at the documentation surrounding upgrades and patches. They make it sound like rocket science. For many of us, doing builds is just a tiny part of our jobs; the docs seem to be written for people who do this full time. I don't have the luxury of sitting back and spending days with this stuff.
I'm also discouraged that from what I've read, I can't automate patch builds with the command line tool. Again, I need to automate all this and put it on our build machine, I can't waste time with the IDE.
Mark
I too would like to automate our patch builds on the command line because I seem to be the only one who understands how to do them and being able to pass the builds off would help me out tremendously.
I handle our "Differential patch updates" a bit different than you do... which I don't know if this is good or bad.
However, I do the build just as it would go on a CD, meaning I build the "latest" version of our MSI in it's "compressed format". So after the MSI is built, I then use the "Patch configuration" to decompress the "latest" and "previous" EACH time I do the build.
The idea behind this is that we ONLY check in the MSI and data1.cab file when the product gets released. This means there is no assumption that the Patch configuration will always be pointing to an existing "decompressed" image of a folder that may or may not exist. It may be stupid, but it's the way I've been doing it.
So, I obviously know I can build the MSI and build the patch on the command line, but I am unsure about the other steps that I do in the IDE, ie "decompress" the MSIs and updating an MSI table below (items in red below):
1. Build the "latest" MSI (can do with automation interface or iscmdbld.exe)
2. Run some command on the MSI to decompress it to my specified "latest" folder (unsure how to do perhaps an "Administrative" install on the MSI????)
3. Update the MsiPatchMetadata table to change the "DisplayName" (have no clue how to do this)
4. Use the automation interface / command line utility to build our patch
Any help would be greatly appreciated!
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)