Hi All,

This may take a while in describing, but I'm totally stumped with what I'm seeing.... OK, here goes.......

We have small PlugIn installs that we administer from a small widget that ships with our Server application. Now forget about patching, Major/Minor/Small updates, etc. Basically our PlugIn installs ship with a change to the Product Version and that is it. The Product Code is always the same.

What happens is that when a user choose to configure a PlugIn for install, the Product Code and the Version of the .msi are written to an .ini file on the server with a flag that indicates action to be taken (install, update, delete).

On the Client side, our update utility will look in the .ini file located in a shared directory on the Server. The Product Code and Version are then written to a local .ini file during the PlugIn install. If the update utility does not find any entry in the local .ini file, but the server .ini indicates the PlugIn should be installed, it is installed. If it finds a matching Product Code with different version and its configured to be updated, it is updated. The update consists of a removal by product code then an install of the new package. If configured on the Server to be deleted, it of course would be deleted during update.

Hopefully that is clear enough.

Now if I test with a particular PlugIn install and install, update and remove, all seems to work properly. Upon removal, its entry is removed as expected from the workstation's .ini file. Now, if I have several PlugIns installed at the same time, and I choose to remove one, all seems to work properly in that I no longer see the app in Add/Rem Pgms. However, for some reason, its local .ini setting is not removed. I can't for the life of me figure out what the problem is.

I should mention I guess that all PlugIns write to the same section [OurApp Update PlugIns] in the local .ini file.

I don't know if this is clear enough for anyone to guess at what is going on. Like I said, forget about the norms of Windows Installer updating as this is the mechanism that has been used for PlugIns for years. It may not be the best, but it works.

Again, I just don't know what is going on. Feel free to ask questions!
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
are those INI entries present in INI Table of your MSI.
Answered 03/27/2010 by: mekaywe
Brown Belt

Please log in to comment
0
I know *exactly* where you're coming from, Matt. Sometimes, this crap just defies common sense. So, in your shoes, I'd take a copy of a known working package and transplant everything from the broken one into the copy, then test.
Answered 03/27/2010 by: VBScab
Red Belt

Please log in to comment
0
The thing is, I've tested this with various PlugIn installs and it seems to happen with different ones.

If I take one of these same 'problematic' installs and run through my test scenario of installing, updating and removing, all looks good. In this instance of course, there is only a single PlugIn entry written to the .ini.

Other than the this .ini entry left behind, all else appears to function properly. Here is the problem, however. Let's say someone configures a PlugIn for uninstall. The next time they run the update utility on the workstation, the PlugIn is actually removed, but the .ini entry remains.

Now, the PlugIn 'administrator' realizes he/she made a mistake and configures the same PlugIn for install to fix the blunder. The update utility looks to the Server's .ini and see's it has to install the PlugIn, but the PlugIn still appears to be installed locally due to the remaining .ini entry in the Workstation's .ini.

I'm totally stumped.

I may do something in our update utility that, after removal, takes the local ProductCode that was just removed, run the remove command line again, get the return and if it indicates the product is not installed, delete the entry from the local .ini. Clunky!
Answered 03/27/2010 by: Superfreak3
Black Belt

Please log in to comment
0
Here's what I have found.... (clean machine)...

Two separate installations write information to the same .INI file in the same section...

[OurCo Update PlugIns]
[ProductCode]=[ProductVersion] (from the .wsi's INI Files view)

It doesn't matter in what order the PlugIns were installed, when the first is removed, two INI entries still remain. When the second is uninstalled, its INI entry IS REMOVED!. Only the first out entry remains.

Like I believe I said earlier, if each is installed/uninstalled separately (as the only PlugIn on the system), The INI entry is removed on uninstall as expected.

What the heck??? Stumped!
Answered 03/29/2010 by: Superfreak3
Black Belt

Please log in to comment
0
Just as an experiment, have you tried adding a comment line immediately following the section:

[OurCo Update PlugIns]
; Some comment or other
[ProductCode]=[ProductVersion] (from the .wsi's INI Files view)

or a dummy entry

[OurCo Update PlugIns]
Whatever=Something
[ProductCode]=[ProductVersion] (from the .wsi's INI Files view)
Answered 03/29/2010 by: VBScab
Red Belt

Please log in to comment
0
I think I found the blunder...

Our template has the INI file as a component. If the Component GUID is changed, problem solved.

Should I also change the component name with each plugin or will the GUID suffice?
Answered 03/29/2010 by: Superfreak3
Black Belt

Please log in to comment
0
Although only the GID is significant, you may as well change both. That way, each package is differentiated "visually".
Answered 03/29/2010 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity