Currently one of our installation packages does something that it should not be doing. It is handling configuration data for several applications. Clearly this created several issues during upgrades. Now, for the next schedule major release, we (the packaging team) decided that we would let the applications handle the configuration information. This was duly presented as a proposal to other "application development" teams in a meeting. The people were a little hot under the collar during the meeting. Other development groups suspected that we were doing this to brush off our responsibility. I am sure that other setup developers would also have faced such similar predicament.
I was recently browsing through the InstallShield Community forums and found that mosth setup developers were invariably including configuration data as a part of their installation. I even saw one post where a setup developer had used a VBScript custom action with the FileSystemObject and tried to replace certain place holder texts in the installed configuration file. I am sure that many of us, who have burnt their fingers with VBScript and FSO, would agree with me. Logically speaking, there is nothing wrong with this approach. But we have to realize that we are introducing a element that can go wrong. Having deferred VBScript custom actions with FSO is a lot of fun while debugging.
My recommended approach would be to have a small configurator utility, which would accept command line parameters and perform the same tasks. This serves two purposes.
- The configuration data is effectively taken out of the MSI. You can avoid slicing and dicing the CustomActionData property to get the desired values. There is one element less in the project that can go wrong.
- The user need not run the installation, if he has specified incorrect configuration. He has the option of configuring the software after installing it. While installing on locked down environments, the setup author has to ensure that the permissions table is authored such that the current user has no problems writing on the the specified resources. This should'nt be a problem for registry keys or folders as their permission tokens can always be altered by the installer.
2 comments:
Hi Blogger, I was out blog surfing looking for some info on wood working blue print when I ended up on your page. Obviously I ended up a little off base, but your topic caught my eye. While I am here, I just wanted to drop a quick note to comment your blog...now to move on and continue my search for wood working blue print. I am going to
bookmark your site for future reference and reading. Should you ever need it, you can get specific information about wood working blue print at the site above.
Quake III Arena or Quake 3, abbreviated as Q3A or Q3, is a multiplayer first-person shooter computer and video game released on December 2, 1999. The game was developed by id Software and featured music composed by Sonic Mayhem and Front Line Assembly. sportsbook, Quake III Arena is the third title in the series and differs from the previous games in the Quake series in that it excludes the normal single-player element, instead focusing upon multiplayer action. The solo experience in Q3 is arena combat versus AI opponents, in a similar style to Unreal Tournament. http://www.enterbet.com
Post a Comment