I have been in this business quite a few years and rarely has one of my clients approached me about having one of my InstallShield packages go thru Windows Certification. Typically my clients are more interested in being able to install and upgrade their software package, where I typically offer the best solution to their needs.
Recently one of my customers informed me that he had submitted one of my recent packages to him to have it tested to achieve the “Certified for Vista Windows Logo”. Basically my customer was a serious ISV Product Vendor for Microsoft and wanted to complete the certification to demonstrate his company’s level of commitment to Microsoft. When he told me that I had numerous thoughts of what could be uncovered; was UAC handled correctly in both the UI Sequence and the Execute Sequence?, did I let a ICE message slip by?, or worst on 64bit OS – were the registry entries correct?
And on top of it – he wanted the package certified to run on Vista – notoriously the hardest to attain because of the additional security issues poised by the UAC.
Actually on the first pass the setup failed on two areas1:
- The version number did not meet Microsoft standards
- There was missing an entry in the Upgrade table
Hmmn, the customer did insist of using a very unique Version number – it started with the year of release, i.e., 2009.0.0 instead of the conventional 1.1.1 format. I actually had sent him an email during the design and development pointing out that using this type of version number may cause problems during future upgrades – and after the failure the customer was already in the process of getting development to rectify what was an internal systems issue.
As for the setup missing an upgrade table, I was confused. Why an upgrade table entry for the initial release? Turns out I had forgotten (or maybe never learned…) that when you send out your initial release with an entry authored into the upgrade table it will prevent situations where the customer tries to install the 1.0 version over the 2.0 version already installed. In this situation the 1.0 version would go out with an upgrade table with the “end” version number set as blank.
This was not bad considering I had not “prepped2” the package, going over all of the details if I had known beforehand that the package was being certified! It does validate my technique of building and testing the package the ensure that it is the best it can be – even if the customer is not expecting it – nor paying additional for the time I put in!
1 There were other areas that initially failed, but they were issues with the application binaries themselves that had nothing to do with the setup itself.
2 In my early years, I was an Air Intelligence office assigned to a fighter squadron VF-14, embarked with the first East Coast F-14 Tomcat’s, and embarked onboard USS John F. Kennedy. During build-ups before the 1974/75 cruise we were selected for a missile shoot using the new F-14 AIM-54 Phoenix missiles. Running about $1 million each, a lot rested on the Tomcat’s first missile shot. Our squadron spent two weeks selecting the best two air-crews, grooming the birds and having the TechRep’s go over the missiles, ensuring the best possible outcome. I always wondered what would have happened when the “balloon went up” and we had to go with “what cha got”…
So, after reviewing the certification test results, here are some issues that you should review when you create a package:
When support the 64bit Version of Operating System
- No Custom Actions that execute 16bit commands
- All device drivers are segregated so that only 64bit drivers are installed.
- No files saved to Windows System32 directory unless via authorized methods (MSM, etc.)
- All executables are digitally signed
- No ICE (Internal Consistency Evaluators) errors in the range of 1-99 are generated.
- Support installation with concurrent users. In addition, you should be able to install under a user that does not have Administrative authority (selecting “Install using…” is permissible)
- Install to correct folders (seems obvious to most of us) – but attention to detail should ensure that all files are installed correctly when using anything other than the default INSTALLDIR value.
- Follows “Best Practices” when creating Components
- Each component has a unique GUID
- Only one COM Server for each component
- Each component has a single Key file designation
- Handles correctly Custom Actions:
- Never named “msi…”
- Does not use Nested Custom Actions
- Rollback Custom Actions employed when required
- Nothing is done to prevent package from being installed from Command Line – especially silently
- Author an upgrade table entry for new installations (ensure the Max Version is blank) Supporting entries in registry required for this to work.
- Entry is created in Add/Remove Control Panel to allow for uninstallation
- A clean Uninstallation can be performed followed by a clean installation.
Hope this helps!