INI entries not removed in certain situations....??????
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!
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
Answers (7)
Please log in to answer
Posted by:
anonymous_9363
14 years ago
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.
Posted by:
Superfreak3
14 years ago
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!
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!
Posted by:
Superfreak3
14 years ago
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!
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!
Posted by:
anonymous_9363
14 years ago
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)
[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)
Posted by:
Superfreak3
14 years ago
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?
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?
Posted by:
anonymous_9363
14 years ago
Although only the GID is significant, you may as well change both. That way, each package is differentiated "visually".
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.