Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

MAJOR UPGRADE -does not remove from add/remove programs


6 replies to this topic

Dejan

Dejan
  • Members
  • 10 posts

Posted 23 November 2001 - 17:49

Hello,
we have one exe (MyApp.exe) file and some html, gif, dll, vxd, sys and txt
files for help, support etc. Every week we make a new release of our
setup.exe that includes all of the above mentioned files. The only change is
made in the MyApp.exe (some new functionalities are added every week). What
we do then is change the product code, project code and project version of
build setup.exe (with option: "cache installation on local machine" if that
is of any significance) and change the version max field in the Upgrade
table of the Direct Editor (if i'm building the 1.09 version, instead of
1.07, that was previously written there, i enter 1.08) and run setup.exe.
Those are all the changes we make before new release is built.
THE PROBLEM is that it upgrades our previous version correctly BUT LEAVES
PREVIOUS VERSIONS IN ADD/REMOVE PROGRAMS. So this morning i had 5 MyApps in
Add/Remove programs  -  sad isn't it?
Question is: am i doing the upgrade as it should be done, considering that
we don't add any new components or features, only change one exe file, and
is this a known IS7 bug or should i add something somewhere in the script or
wherever.
Thank you in advance, the answer, whenever it comes would mean a lot to me.
Oh yes: it's a standard project, IS 7 developer, Media type: web; Web type:
one executable;
10x again to anyone who even tries to help   :-)))

mandrews

mandrews
  • Members
  • 44 posts

Posted 26 November 2001 - 17:01

I'm hoping we can help each other out.

Although I've worked with InstallScript for some time, I've only been working with the installer tables for a few months.

My company is also interested in the ability to bump up the user's install to the next version using another full install, and not just a patch.

First a question:
It seems in many places in the documentation it says when changing the version of the same product, you want to ONLY change the Package Code and the Product Version.

Do you find that you must also change the Product Code and append the Upgrade Table to get another full install to update the user correctly?

I will gladly jump into working on this angle with you if this proves the best method to get the job done.

Here's my help so far:
Have you tried moving the "RemoveExistingProducts" action way down to after "InstallFinalize" action?
Because...

ARTICLE IN SDK: "Major Upgrades"
... When the FindRelatedProducts action detects that an affected product is installed on the system, it appends the product code to a property in the ActionProperty column of the Upgrade table. The RemoveExistingProducts action and the MigrateFeatureStates action remove or migrate the products listed in the ActionProperty list.

ARTICLE IN SDK: "RemoveExistingProducts Action"
  ...
The RemoveExistingProducts action must be scheduled in the action sequence in one of the following locations.
  ...
4. After the InstallFinalize action. This is the most efficient placement for the action. In this case, the installer updates files before removing the old applications. Only the files being updated get installed during the installation. If the removal of the old application fails, then the installer only rolls back the uninstallation of the old application.

If you find the answer, please post as I'm trying to do the same thing by whatever method works.


mandrews

mandrews
  • Members
  • 44 posts

Posted 26 November 2001 - 21:36

I went back to just changing the Package Code and the Product Version and stumbled upon this article in the Installer SDK:
"Small Updates by Reinstalling the Product"

...and I seem to have had good luck using its method by just running this from the command line:

msiexec /fvomus [path to updated .msi file]

Example:
msiexec /fvomus MyApp.msi

Suprisingly, it seems to work fine on the Standard projects with a couple of minor bugs I've seen so far:
1) Doesn't seem to change version number listed in Support Information (2k, XP) in Add/Remove Programs.
2) Having a problem getting it to change my desktop icon (the icon has changed in the versions I'm testing), though the Start Menu and Add/Remove icons change correctly.

You can put the above command line in a batch file, or if you want something cleaner I'm making a small Win32 app called "Update.exe" in Visual C++ with the following code:


////////////////////////////////

#include <windows.h>

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
STARTUPINFO si;
   PROCESS_INFORMATION pi;

   ZeroMemory( &si, sizeof(si) );
   si.cb = sizeof(si);
   ZeroMemory( &pi, sizeof(pi) );

   // Start the child process.
   if( !CreateProcess( NULL, // No module name (use command line).
       "msiexec /fvomus MyApp.msi", // Command line.
       NULL,             // Process handle not inheritable.
       NULL,             // Thread handle not inheritable.
       FALSE,            // Set handle inheritance to FALSE.
       0,                // No creation flags.
       NULL,             // Use parent's environment block.
       NULL,             // Use parent's starting directory.
       &si,              // Pointer to STARTUPINFO structure.
       &pi )             // Pointer to PROCESS_INFORMATION structure.
   )
   {
       MessageBox (NULL, "CreateProcess Failed", NULL, MB_OK);
   }

   // Wait until child process exits.
   //WaitForSingleObject( pi.hProcess, 10000 );

   // Close process and thread handles.
   CloseHandle( pi.hProcess );
   CloseHandle( pi.hThread );

return 0;
}


Dejan

Dejan
  • Members
  • 10 posts

Posted 27 November 2001 - 12:58

>>I'm hoping we can help each other out.
-- :-))  that would be great

>>Do you find that you must also change the Product Code and append the Upgrade Table to get another full install to update the user correctly?
-- yes i do

>>Have you tried moving the "RemoveExistingProducts" action way down to after "InstallFinalize" action?
-- nope, i'll try this today, unless you have tried and failed

>>If you find the answer, please post as I'm trying to do the same thing by whatever method works.
-- don't worry, i will

>>Suprisingly, it seems to work fine on the Standard projects with a couple of minor bugs I've seen so far:
1) Doesn't seem to change version number listed in Support Information (2k, XP) in Add/Remove Programs.
-- that would be ok, i guess, with my boss   :-)))

>>2) Having a problem getting it to change my desktop con (the icon has changed in the versions I'm testing), though the Start Menu and Add/Remove icons change correctly.
-- well, here's where i have a question. how can i choose the icon for add/remove programs? desktop and start menu icons are the ones that i have chosen but not in add/remove...
So to make it completely clear, what you do is change Product version and Package Code (no Upgrade table involved) and run msiexec /fvomus MyApp.msi from Update.exe, right? But how can i do that when my MyApp.msi is in setup.exe? Also, i have found some things in MSI Help, like ARPNOREMOVE flag (try that word under search) and i'm trying to make it work. still no luck, but as i have a lot of things to do, maybe today i'll have more free time for the IS7.
Anyway, 10x for the help and i hope that together we'll find the solution.
Best Regards,
Dejan


mandrews

mandrews
  • Members
  • 44 posts

Posted 27 November 2001 - 20:18

Found some good information for general understanding of Windows Installer here:
Installsite.org Menu > News > New and Popular > Popular Topics > Updates and Patches

The things suggested there seem to work until you bring in Dev7's Setup.exe (as an unknown variable) and stuff starts breaking.

For instance the "Upgrading Without Patching" article was last updated in February 2001 and seems to be written for IPWI.  If you follow the steps exactly, it doesn't work in Developer.

In everything I've read (so far) in order to have control over msiexec, you have to send it switches and parameters.  Developer's Setup.exe seems to send it's own switches to msiexec.exe and you have no real control.  We've already seen that if you bypass it and run your own command line, everything updates fine.

So for now it would seem that we are forced to deal with two different executables - one for first installs (Setup.exe) and another to update (custom executable). I was toying with the idea of using the Update.exe I made before and wrapping everything up in Package For The Web.

However, if you're dealing with the internet and downloads, a patch may be the way to go since the patch size should be a smaller download.

For CDROM's, a custom main menu for the CDROM seems to be in order that allows the user to choose "Install" or "Update an existing install" each pointing to a different executable, that in turn point back to the single .MSI file.

I'll keep banging on it, but that's how it's looking right now.

Note:  I haven't worked with patches a whole lot yet, but I'm going to need it for some upcoming projects so I'll see what kind of trouble I can get in there.

Regarding your other question, the icon in Add/Remove Programs is found here in Developer:
General Information > Windows 2000 > Display Icon


JonB

JonB
  • Members
  • 12 posts

Posted 01 December 2001 - 00:07

I am posting my experiences and observations, in the hope that it helps someone else.

---

I am also using "major upgrade" to do what are effectively minor or "point" updates to my application, because I can't be sure exactly what each update will require.  The automatic uninstall-then-install capability is exactly what I wanted.  Users can only have one 1.x version installed at a time, and attempting to install a 1.y version automatically uninstalls the 1.x version.

I found that I had to change the Product Code.  Otherwise I got strange behavior -- the progress bar did weird things, and certain files/directories created by featurexxx_Installed 'event' functions were not getting created (or were being deleted after the fact?)

My interpretation of the reason for this is -- in order for WI to uninstall it, it needs a separate product code.  It's the *upgrade code* that essentially says, "these are related products".  Indeed, one of the actions is "FindRelatedProducts". Essentially, what WI calls the "upgrade code" is a unique code for a single product.  The "product code" and "package code" kinda go together as identifying a particular version of the product.  

I went to look at the webcast on 'upgrades' and found it was mostly regurgitation of the documentation, or vice versa.  One point that I did pick up, was that I had set the versions in the upgrade table backwards -- if you want the user to be able to install any version (even an earlier one), then set VersionMin to the lowest possible version, and then it will automatically uninstall *whatever* version they have, and install the one they're now running.

Anyway, regarding the duplicates in the ARP dialog, it appears they are controlled by registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield_{6ECC4CAB-C793-4DF1-828B-4A7FF4A6C591} where the last number is the product code.  

I started to look into this further, and tested installing version 1.1 to one directory and 1.2 to another, and found that NOTHING got uninstalled.  

So I looked into that further, and found that you have to fill in a value for the "Remove" column in the upgrade table.  This is a list of features to uninstall from the old product.  If you put in "ALL", then it removes all features, which is what I wanted.  

When I did this, the duplicate disappeared from the ARP dialog.  However, the ARP dialog appeared to delete the wrong duplicate.  This appears to be merely a quirk of the display.  If I close the ARP window, and re-open it, the correct one appears.

Whew!


Dejan

Dejan
  • Members
  • 10 posts

Posted 13 December 2001 - 17:05

Thanks mandrews, thanks JonB!!!

Also i apologize to You for not writing for several days.
Anyway, i finally got rid of those duplicates and that registry key that JonB mentioned was what really caused the ARP problem. Looking deeper into the problem, it seems that ActionProperty in the Upgrade table ( = Property Manager > SecureCustomProperties ) -  "OLDPRODUCTS" (or whatever you name it) doesn't hold values for older products with the same upgrade code.
... Well, that was that...
Thank You again and all the best to You two.
Regards,