|
Backgrounds of Software Conflicts Conflicts in software packages
The terms "conflict solving", "conflict validation" and "conflict resolution" are interpreted variously within the context of software packaging and by different software solutions: With some tools, for example, we find rule violations in the local design – self-contained and covering the entire software package – as the cause of conflicts (ICE conflicts). In other tools, "software conflicts" describe the installation of a specific file from one software package into a common environment with a file that has the same name, but a different version number and comes from a different software package. Such tools recognise this situation and recommend replacing the file with the lower version number in the relevant software package during the repackaging process or subsequent conflict management operations. And, lastly, one generally refers to software conflicts in cases where a software package uses COM components that register themselves during installation via the DllRegisterServer() function or via other implemented registry mechanisms (e.g. a registry table from the MSI file). In that case, problems can occur that are also referred to collectively as "software conflicts" and which are generally known as "DLL Hell". These occur when the above-mentioned COM components are ultimately shared between a number of different programs, and where existing registry values are overwritten with new references, existing COM components are overwritten with versions of the shared files that are not really entirely compatible, or where registry references that relate to the DLL or OCX are deleted during the uninstall process or when upgrading a software product.
Naturally, there are many other types of software conflicts present in software packages. What they all have in common, is that they manifest themselves as problems only in subsequent operations: they may occur as a result of the shared use of different software products or the interplay between software elements and the operating system, or before or after the installation status of software has been changed (installing, uninstalling, etc.). The consequences are extremely variable. While in one case the conflict may mean that the software cannot even be installed successfully, in other cases it may lead to the complete failure of certain software packages or only to the failure of certain functions. In the latter case, the execution of certain functions from these software packages may itself then have deleterious effects. Within the company, such behaviour may be observed generally – across the entire infrastructure – or may well only occur under certain configuration conditions. Since, as we have seen, there is a wealth of different conflict types, the subsequent analysis and identification of the conflicts is frequently an extremely difficult, time-consuming process, which also requires an understanding for complex interrelationships. This is also the reason why the root causes of problems often remain hidden, and one tends to not pay enough attention to the topic of "software conflicts in software packages" – since one has not correctly identified prior fault scenarios as being caused by software conflicts. This underlines the importance of professional software conflict management, which focuses on the proactive resolution of error scenarios – blocking the effects of software conflicts before they have a chance to spread. Conflict management with Conflict Explorer 2009
When categorising software conflicts from software packages, we distinguish the following major groups:
- Conflicts arising from rule violations in the design of a software package, when considering local rules that are mostly restricted to the software package itself (e.g. ICE conflicts, Internal Consistency Evaluators)
- Conflicts arising from global design errors and design configurations within a collection of several software packages, or from the interplay between software and the operating system.
Conflict Explorer 2009 identifies and resolves conflicts that belong to the second group described above. We can now further subdivide this second group (the following list is not conclusive): - Conflicts arising from shared resources (between software packages or between the software package and the operating system), where the resource is removed when uninstalling or upgrading a software package, thus leading to problematic situations.
- Conflicts arising from shared resources with variant content. One example is where identical keys with different values are used by INI file entries that have the same file name in different software packages. Identical registry keys with different values that are used in multiple software packages also belong to this group.
Conflicts arising from defective component design, when considering global rules (different KeyPath for "identical" components with the same ComponentId, different resources for "the same" components, etc.)
Moderate investments and transparent modifi-cations that significantly improve the quality of your software packages easily repay their costs!
If one considers the overall costs involved in an application life cycle, one finds that software packages that are robust and of a high quality will be responsible for far less total expenditure than packages that do not meet these standards. Especially when considering the deployment of Conflict Explorer 2009, the investments that bring additional value are insignificant when compared to the costs that may be incurred if one does not deploy software conflict management. After all: a software deployment process without effective software conflict management may ultimately grow to represent an incalculable risk.
In discussions with software packaging experts, one is occasionally confronted with the statement that one has never actually had any software conflict problems. However, in the vast majority of cases, this merely confirms the fact that one has simply not appreciated the effects of software conflicts directly. In scenarios where corporate computer users identify a malfunction in a software package, they often try to tinker with it themselves, aiming to identify the root cause of the error. There is, of course, nothing wrong with this approach. Yet valuable minutes or even hours can pass before the user, exasperated by the problem, finally picks up the phone to ring the company's IT support. Even at this stage, the company has already incurred considerable costs. In many cases, assuming IT support is also unable to resolve the problem after a while, staff will then request or order the reinstallation of the affected software package. Occasionally, even the entire system will be reinstalled. We don't even want to mention the loss of image that the IT services suffer in the eyes of their customers. Considerably worse are the costs stemming from the efforts of all parties involved (user, company support, units responsible for software distribution and installation, etc.). Considering the company as a whole (conflict situations generally occur on multiple occasions), these costs can assume dramatic proportions. The key factor in the whole scenario is that the software packaging team itself never hears of any of these effects – nor, of course, does it work to identify their causes. Even in individual cases where a clear localisation of the cause was possible, the unavoidable solution is to correct the affected software package. This in itself incurs new expenditure.
By deploying Conflict Explorer 2009, one realises the consequences of deciding not to utilise an integrated, automated software conflict correction process, featuring a highly proactive design model. In a mid-sized company with a triple-digit software pool, it is not unusual to find software packages containing several thousand individual conflicts with other software packages or the operating system. While working with an even larger company, we found that around 25 to 30% of the company's software packages had untreated software conflicts. This value is naturally dependent on the number of imported and deployed software packages, and increases with the size of the deployable software pool.
Is there any sense in deploying Conflict Explorer 2009 if other Windows Installer developer tools with conflict features are already being used?
Most Windows Installer developer tools used internal and local consistency checks (Internal Consistency Evaluators, ICE) to carry out package validation. An ICE validation checks the package database for entries that are individually valid, but which could cause erroneous behaviour in the context of the entire local database.
Conflict Explorer 2009 expands the checking algorithms from the local level to a corporate or other global perspective, and makes it possible to display potential conflicts within a heterogeneous desktop environment. In addition, Conflict Explorer 2009 also enables automated conflict resolution via a robust transform file, which is added to the Windows Installer package. The exact nature of these modifications depends on best practice rules. The action is transparent, and can also be used for all types of Windows Installer packages without needing further modification. In addition, many features distinguish it from similarly-conceived tools. These features aim to place the focus on software packagers and their needs, and to ensure that their successful use does not negatively impact the speed of the software deployment process. Conflict Explorer 2009 can be used as a standalone application. However, integrating it into existing environments within the software deployment process is an equally simple matter. In addition, it can expand any existing software conflict management solutions with a range of professional functions that cannot as yet be found anywhere else.
Additional features are discussed at Features and Highlights
|
