When migrating your applications to a new platform, you not only want to make sure that your applications will be compatible with the new target environment but you also want to know if all your applications will work when you install and uninstall them together on that target environment.
Conflict Management is a method of addressing inter-application conflicts and conflicts against the Operating System. There are a number of problems that are encountered, especially if a number of applications are installed and uninstalled on a system. Understanding the internal relationship between applications is a time-consuming and extremely difficult process. Often these issues remain hidden until the software is deployed to your users or a new version of an application is deployed. While application virtualisation takes away the need to conflict manage your applications and huge improvements have been made to our target platforms (Windows Resource Protection for example) and software development processes to alleviate these issues, there is no silver bullet solution. Many of you out there will still have a number of core applications installed on the Operating System and want to make sure that other applications you install there won’t conflict with one another.
Common issues we want to detect:
1. Incompatible Versions - A particular version of a library may be incompatible with an older or newer version. There have been many rules put in place to prevent these situations but this can still occur particularly with older applications. Many applications relied on the bugs that existed in these libraries and when a new version is released where the functionality is fixed they don't function any more.
2. DLL Stomping - Different installers have the ability to replace libraries on the file system with older versions. Software vendors often wrote installers that ignored versioning rules as a consequence. Windows Installer handles these correctly and will only be able to update any library if it has a newer version. With Windows 7 we can also sleep a bit better because Windows Resource Protection means that the Operating system will prevent certain files and registry keys being replaced if they are not installed with the "trusted installer".
3. Incorrect COM Registration - In COM the registry is often used to determine the underlying resource that should be used. If the COM information in the registry is overwritten and now links to another resource, this other resource would be used instead, which can cause an application to fail.
4. Shared-in memory modules - This only applies to 16bit resources. 32bit and 64bit resources can be loaded into the memory simultaneously apart from when they are in the same folder when memory-mapping will occur.
Other issues that we have want to know about:
· INI Files being overwritten
· Registry Values being replaced
· ODBC settings being overwritten
· File Associations being replaced
· Files and Registry keys that will be removed during uninstallation.
Here at ChangeBASE we have developed just a tad under 40 rules for our software AOK that will inform you when one of the above scenarios is encountered. With our new Workbench Release you will be able select exactly which rules you would like to run for your applications.
Here is a sneak preview of what's coming your way: