Repackaging a self updating package
Hi All,
We plan to roll out an application called Tramps by Trace Group which will be a core line of business application. Unless the application is installed manually (its a non-msi, setup.hta file) their in-built self updating tool won't work meaning regular repackaging of the updates (which unfortunately occur frequently). This may be fine but a more ideal solution would be a package that was able to be rolled out but was also able to self update using their update mechanism. The only problem with this is that the self healing feature of Windows Installer will cause the package to re-install itself after each update reversing the changes that the update performed.
Has anyone got any advice regarding repackaging an application model such as this? Any suggestions would be greatly appreciated.
We have put a lot of effort into making our systems fully managed by only allowing Windows Installer packages. We don't want to take a step back and do a manual install of this application especially because it is likely that Trace will eventually create an MSI due to customer demand.
We plan to roll out an application called Tramps by Trace Group which will be a core line of business application. Unless the application is installed manually (its a non-msi, setup.hta file) their in-built self updating tool won't work meaning regular repackaging of the updates (which unfortunately occur frequently). This may be fine but a more ideal solution would be a package that was able to be rolled out but was also able to self update using their update mechanism. The only problem with this is that the self healing feature of Windows Installer will cause the package to re-install itself after each update reversing the changes that the update performed.
Has anyone got any advice regarding repackaging an application model such as this? Any suggestions would be greatly appreciated.
We have put a lot of effort into making our systems fully managed by only allowing Windows Installer packages. We don't want to take a step back and do a manual install of this application especially because it is likely that Trace will eventually create an MSI due to customer demand.
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
spartacus
17 years ago
First point to note is that is generally not a good idea to permit users to be able to update their own software "ad-hoc" as you then lose significant control of the application in your target estate. Can the application, for example, be run from server rather than run locally ? If it could then you could make your regular updates to the server ensuring that all users are running at the same level.
If this idea is a non-starter then you will probably need to get more information from Trace regarding what changes their regular updates make. If there is a fairly predictable pattern of changes, you could try to exempt any affected components in your package from self-repair.
To acheive this, you could, for example, make sure that any components in your MSI affected by the updates do not have a keypath set, or even give the components a blank component GUID - pretty it aint, but it would work !
Both approaches would work best (IMHO) if you make sure that you have set up one component for each of any affected files. That way, all of the remaining "static" files could still be included normally in any self-repair process.
Given that the vendor intends to eventually ship an MSI, you should also ask them what their strategy will be for regular updates thereafter - do they, for example, plan to make MSP patch files available for the this purpose ?
Regards,
Spartacus
If this idea is a non-starter then you will probably need to get more information from Trace regarding what changes their regular updates make. If there is a fairly predictable pattern of changes, you could try to exempt any affected components in your package from self-repair.
To acheive this, you could, for example, make sure that any components in your MSI affected by the updates do not have a keypath set, or even give the components a blank component GUID - pretty it aint, but it would work !
Both approaches would work best (IMHO) if you make sure that you have set up one component for each of any affected files. That way, all of the remaining "static" files could still be included normally in any self-repair process.
Given that the vendor intends to eventually ship an MSI, you should also ask them what their strategy will be for regular updates thereafter - do they, for example, plan to make MSP patch files available for the this purpose ?
Regards,
Spartacus
Posted by:
dreamsurfer141
17 years ago
Hi Spartacus,
Many thanks for your sound advice and prompt reply.
Unfortunately its a Client-Server application (essentially a front-end to a SQL database) which pushes files to the clients as well when there is an update on the server.
The application will be used by approximately 120 users. ~60 of which will use it through Terminal Services at our other sites which leaves a possible ~60 manual installs. However, agreeing with your first point, giving control to users to update could potentially cause any number of strange problems because there is an option to click "No" to the update! This leads me to a definite decision against their own update mechanism and try and design a Windows Installer package.
I will do some testing with their updates and try and create a Windows Installer package using the techniques you mentioned and will let you know how I get on...
Many thanks for your sound advice and prompt reply.
Unfortunately its a Client-Server application (essentially a front-end to a SQL database) which pushes files to the clients as well when there is an update on the server.
The application will be used by approximately 120 users. ~60 of which will use it through Terminal Services at our other sites which leaves a possible ~60 manual installs. However, agreeing with your first point, giving control to users to update could potentially cause any number of strange problems because there is an option to click "No" to the update! This leads me to a definite decision against their own update mechanism and try and design a Windows Installer package.
I will do some testing with their updates and try and create a Windows Installer package using the techniques you mentioned and will let you know how I get on...
Posted by:
aogilmor
17 years ago
I have seen this type of scenario, and it can sometimes work if you open up a data directory c:\program files\app dir\data, but if it it tries to updates system files forget it. Either make it a network link if possible, as spartacus suggests, or make it manual :-(
Posted by:
AngelD
17 years ago
I remember something similar on my last project.
We just decided to not allow regular users write access to the Program Files\app folder and when it was time to update we had a patch or just an update package.
We just decided to not allow regular users write access to the Program Files\app folder and when it was time to update we had a patch or just an update package.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.