installation standards
I’m looking for some information on common standards that could be applied when developing installations.
The type of installations I am talking about are server and client setup.exe’s & msi’s which are developed by a software vendor and will be distributed to various clients across numerous different windows operating systems.
Any info would be greatly appreciated!
The type of installations I am talking about are server and client setup.exe’s & msi’s which are developed by a software vendor and will be distributed to various clients across numerous different windows operating systems.
Any info would be greatly appreciated!
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
yarborg
16 years ago
A few things to focus on here would be to make sure that the installations have the ability to install and uninstall silently. Be sure to include support for a /? if you are doing anything out of the ordinary which should display a list of available command line options.
MSI's are already going to have a standard built into them. When I say standards I mean they use the same command line switches for running silently and uninstalling. You can find a list of typical MSI command line switches here http://support.microsoft.com/kb/227091. Exe's are a different story as they are built using any number of scripts. If you are using Wise to package then usually a /S would be the silent switch but installshield many times uses a setup response file. More than anything it is best to design your own standard with Exe's and stick to it each release to make support easier. You may have to customize the support for uninstall in some areas such as stopping services before removing files. That can be a little tricky but it's important.
Another thing to keep in mind is how do they update other versions. They should be smart enough to either uninstall a previous version and install the new or update the files necessary. MSI's can be a pain here depending on the complexity of the install. Exe's are a little more straight foward but you have to build in the logic to do the upgrade\uninstall.
Finally I would say logging is important. Most logging is done natively in installers but if you are doing anything in your MSI or Exe outside of the normal process make sure it is logged.
Hope that helps. I know its not real specific.
MSI's are already going to have a standard built into them. When I say standards I mean they use the same command line switches for running silently and uninstalling. You can find a list of typical MSI command line switches here http://support.microsoft.com/kb/227091. Exe's are a different story as they are built using any number of scripts. If you are using Wise to package then usually a /S would be the silent switch but installshield many times uses a setup response file. More than anything it is best to design your own standard with Exe's and stick to it each release to make support easier. You may have to customize the support for uninstall in some areas such as stopping services before removing files. That can be a little tricky but it's important.
Another thing to keep in mind is how do they update other versions. They should be smart enough to either uninstall a previous version and install the new or update the files necessary. MSI's can be a pain here depending on the complexity of the install. Exe's are a little more straight foward but you have to build in the logic to do the upgrade\uninstall.
Finally I would say logging is important. Most logging is done natively in installers but if you are doing anything in your MSI or Exe outside of the normal process make sure it is logged.
Hope that helps. I know its not real specific.
Posted by:
kkaminsk
16 years ago
I think this is required reading for both vendors and repackagers.
http://blogs.msdn.com/windows_installer_team/archive/2006/05/01/587990.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/05/12/595950.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/05/24/605835.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/06/27/648447.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/07/28/681358.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/09/18/tao-of-the-windows-installer-part-6.aspx
But a new and bold tactic would be to release your application as a virtual application to reduce support complexity. I know SAP is using Thinstall for their client peice and you can get software vendor pricing for that solution. It might be too cutting edge today but I can see the potential for virtual application environments being offered by many vendors in the near future.
http://blogs.msdn.com/windows_installer_team/archive/2006/05/01/587990.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/05/12/595950.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/05/24/605835.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/06/27/648447.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/07/28/681358.aspx
http://blogs.msdn.com/windows_installer_team/archive/2006/09/18/tao-of-the-windows-installer-part-6.aspx
But a new and bold tactic would be to release your application as a virtual application to reduce support complexity. I know SAP is using Thinstall for their client peice and you can get software vendor pricing for that solution. It might be too cutting edge today but I can see the potential for virtual application environments being offered by many vendors in the near future.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.