kweatherhead
03-31-2006, 08:39 AM
Greetings,
Quick backgound... I have built several single module installers with SF7 and until recently haven't been bit. The installers have all consisted of a database runtime, our application, documentation along with a few additional support files thrown in for good measure.
We recently got burned on an install where we somehow didn't get the runtime fully updated, or maybe an old piece didn't get removed in the process, whatever the issue was as when we uninstalled the previous runtime and then reinstalled the current version, the problem went away and we have not been able to re-duplicate the issue (yeah for intermittent issues), something that is not suppose to have to be done according to the vendor.
I have now started looking into the "Dependency Module" as maybe the proper method to attempt to handle this and we are waiting on the vendor to give us the proper files for making the version specific determination.
What I am trying to determine, along with the Dependency comment above is whether what I want to do (outlined below) would better be multiple (and possibly emebdded) installers or by packages...
The RunTime (RT) support is about 35MB
The specific module code is about 1-2MB/each
The Common files/tables are another 1-2MB/in total
What we want to be able to do is this...
1. Determine version of RunTime and update if the installer contains newer (Dependency Module seems to allow us to accomplish this properly...)
Note: if RunTime is updated the uninstaller has to updated, but only one version of the RT and RT_Uninstaller should be on the system unless the version major has changed in which case the new RT major would be installed in a folder parallel to the highest patched version of the previous major (i.e. version 6 -vs- version 7)
2. Prevent the RT from being removed unless ALL application modules have been removed and the Common Files component has been removed.
3. Be able to control the Add/Update/Remove of any/all of the modules.
4. Be able to control the Add/Update/Remove of the Common Files, but again only allow these to be removed after all of the App Mods, but before the RT.
Additional Requirements...
There are currently two modules completed, the third is well underway and there are about 8-10 modules in the total plan.
Is this a Packages -or- a multiple installers type of installation?
I would appreciate any guidance and recommendations as this is now getting to be a much more complicated environment than we first started out with. I believe we selected the right tool for the job, we simply need a little direction from some more experienced builders as to how to best utilize our investment.
Thanx,
Keith
Quick backgound... I have built several single module installers with SF7 and until recently haven't been bit. The installers have all consisted of a database runtime, our application, documentation along with a few additional support files thrown in for good measure.
We recently got burned on an install where we somehow didn't get the runtime fully updated, or maybe an old piece didn't get removed in the process, whatever the issue was as when we uninstalled the previous runtime and then reinstalled the current version, the problem went away and we have not been able to re-duplicate the issue (yeah for intermittent issues), something that is not suppose to have to be done according to the vendor.
I have now started looking into the "Dependency Module" as maybe the proper method to attempt to handle this and we are waiting on the vendor to give us the proper files for making the version specific determination.
What I am trying to determine, along with the Dependency comment above is whether what I want to do (outlined below) would better be multiple (and possibly emebdded) installers or by packages...
The RunTime (RT) support is about 35MB
The specific module code is about 1-2MB/each
The Common files/tables are another 1-2MB/in total
What we want to be able to do is this...
1. Determine version of RunTime and update if the installer contains newer (Dependency Module seems to allow us to accomplish this properly...)
Note: if RunTime is updated the uninstaller has to updated, but only one version of the RT and RT_Uninstaller should be on the system unless the version major has changed in which case the new RT major would be installed in a folder parallel to the highest patched version of the previous major (i.e. version 6 -vs- version 7)
2. Prevent the RT from being removed unless ALL application modules have been removed and the Common Files component has been removed.
3. Be able to control the Add/Update/Remove of any/all of the modules.
4. Be able to control the Add/Update/Remove of the Common Files, but again only allow these to be removed after all of the App Mods, but before the RT.
Additional Requirements...
There are currently two modules completed, the third is well underway and there are about 8-10 modules in the total plan.
Is this a Packages -or- a multiple installers type of installation?
I would appreciate any guidance and recommendations as this is now getting to be a much more complicated environment than we first started out with. I believe we selected the right tool for the job, we simply need a little direction from some more experienced builders as to how to best utilize our investment.
Thanx,
Keith