AdminStudio at AppDeploy.com
User Forum: Package Creation
Packages: Application Specific Deployment Tips

ConflictSolver

The ConflictSolver program is used to identify, report and, in some cases, even solve conflicts between Windows Installer applications.

It is interesting to note that when importing Microsoft's famous DATA1.MSI from Office 2000 a good number of warnings and errors were detected during the validation process, "Validation has detected the following 211 infos, 1575 warnings, 24 errors."

This ability to detect and solve conflicts between your MSI packages is very helpful, but until this release was ConflictSolver was missing a key item to be considered when looking for conflicts- your operating system with any previously deployed applications. If you typically build a new system with an image that contains common applications, this is what we are talking about. Even if you do want to go 100% MSI and really reap the benefits of the ConflictSolver tool as well as Windows Installer's native abilities to handle conflicts and corruption, you need a starting point. Now you can read the contents of a baseline system into the ConflictSolver database and ensure these elements are taken into account when performing future conflict detection operations.

Once you add your baseline with the OS Snapshot utility and add any MSI files you wish to check against, you can check the package of your choosing against the others (or a subset of the others) in the database. The database may be SQL or Access- a benefit of this is you likely have a method for backing up databases already and this information can be preserved in the same way.

In our test we imported Office 2000, Adobe GoLive 5.0, Diskeeper Workstation and Easy CD creator 5.0 which all ship with MSI setups natively. When checking Office 2000 against the others for conflicts a few were detected...

Because the resolution for each of these conflicts was manual, the checkboxes associated with them were disabled. There is an Internet hyperlink that provides you more information on the problem and the recommended course of action. Within the Wizard, it is difficult to read details on the problem, as when you scroll to the right far enough you see that the entire text is not displayed. The links for the errors we encountered were Application Conflict Evaluator (ACE) numbers 8,10 and 17.

The resolution for each was a manual action, but because no more detail could be obtained from here, we had to go back into the ConflictSolver output window to obtain the detail on these errors. The text can be lengthy requiring quite a bit of scrolling to view all the text, an entry was cut and pasted below from one of the encountered ACE08 errors:

The File version '6.0.8267.0' of file 'MFC42.DLL' in Component 'Global_VC_MFC42ANSICore.51D569E2_8A28_11D2_B962_006097C4DE24' in Package 'Microsoft Office 2000 Premium' conflicts with the same file in Component 'Global_VC_MFC42ANSICore.51D569E2_8A28_11D2_B962_006097C4DE24' in Package 'Easy CD Creator 5 Platinum'. The correct version is '6.0.8447.0'.

With this we can see that MFC42.DLL exists in both packages. By reading the web link associated with ACE08 we learn that the resolution is to manually Change the file versions to match those of the GUID in the Conflict Database, or change the source GUID.

It cannot be denied that this is a very helpful tool that can save you hours of work if discovered after you have deployed a conflict. However, assistance in dealing with problems that cannot be automatically resolved would be even more helpful. Below is a table of the Application Conflict Evaluators from InstallShield's website.

For details on each of these rules, click here.

ConflictSolver may automatically correct entries listed in green (5), those in red must be corrected manually (12). In many cases you would not wish to have ConflictSolver handle a problem where a decision on your part is needed. For example, when asked why the ACE08 error above was not automatically corrected, InstallShield pointed out that it cannot be automatically determined if the new file is backwards compatible in your particular production environment. If it were not compatible you would need to alter the new install or skip rolling out the package all together. It would be nice however if ConflictSolver were able to facilitate this manual process.

But what about the growing number of applications shipping natively as Windows Installer (MSI) setups? To customize these, you need a transform (MST) file and InstallShield Tuner does a great job of handling this task. 

Read on...

[Previous]  1  2  3  4  5  6  [Next]

• Log on
• Register
• Survey Results