I have come across an unexpected behaviour on application uninstall.
A client installs more than one application I developed (say 2) and both use a series of custom components that are designed to be shared. When the second app is uninstalled it removes custom components installed by the first app. Result - first app no longer works.
APP#1:
set to install...
c:\progfiles\clientco\app1\file1.exe
c:\progfiles\commonfiles\myco\comp1.ocx
c:\progfiles\commonfiles\myco\comp2.ocx
APP#2:
set to install...
c:\progfiles\clientco\app2\file1.exe
c:\progfiles\commonfiles\myco\comp2.ocx
c:\progfiles\commonfiles\myco\comp3.ocx
Uninstalling app#2 removes
c:\progfiles\commonfiles\myco\comp2.ocx
All the components are versioned and the 2 installs use the same ocx.
Surely the uninstall should only remove files it actually installed?
What is the version checking and overwrite scheme used by AI when installing?
Pete
Suggested Articles
-
Pete Furness
- Posts: 16
- Joined: Fri Feb 20, 2004 9:34 am
- Location: SURREY, UK
Windows Installer has strong versioning and usage counting rules. These rules are implemented in respect to Components.
Components are the basic building blocks of any installation package. They may be files, registry keys, etc. Among their characteristics are a KeyPath and a GUID. These are used to uniquely identify a component.
Currently, Advanced Installer generates components under the hood for each file, folder, registry key, etc added to the installation. Each generated component is new and unique. This is why Windows Installer does not recognize the single file installed for your application as being the same.
In the next version (1.7) you will have the ability to edit a component's attributes and thus make sure that a component stays the same in 2 installations.
In order to obtain that today, you need to edit the .AIP files, identify the component in both projects and change them to have the exact same attributes (guid, keypath, etc). in both.
Cata
Components are the basic building blocks of any installation package. They may be files, registry keys, etc. Among their characteristics are a KeyPath and a GUID. These are used to uniquely identify a component.
Currently, Advanced Installer generates components under the hood for each file, folder, registry key, etc added to the installation. Each generated component is new and unique. This is why Windows Installer does not recognize the single file installed for your application as being the same.
In the next version (1.7) you will have the ability to edit a component's attributes and thus make sure that a component stays the same in 2 installations.
In order to obtain that today, you need to edit the .AIP files, identify the component in both projects and change them to have the exact same attributes (guid, keypath, etc). in both.
Cata
-
Pete Furness
- Posts: 16
- Joined: Fri Feb 20, 2004 9:34 am
- Location: SURREY, UK
Thanks Cata
That will work fine for components I own and written by me.
However, the installation package might also include third-party files (mostly Microsoft) say something like comdlg32.ocx or mscomctl32.ocx that reside in the winsysdir.
Other applications (not written by me) may use either theirpackage.msi or theirsetup.exe to install the file(s) after installing mypackage.msi. If they then uninstall mypackage and this removes the support files, the other apps will subsequently fail.
This cannot surely be an uncommon issue as for years Microsoft has promoted the notion of these "shared" files and there are hundreds out there from many vendors - all used and distributed (installed) as part of developer's applications.
A workaround would be install but never uninstall these third-party files. Is there some way I can set this up in AI?
Pete
That will work fine for components I own and written by me.
However, the installation package might also include third-party files (mostly Microsoft) say something like comdlg32.ocx or mscomctl32.ocx that reside in the winsysdir.
Other applications (not written by me) may use either theirpackage.msi or theirsetup.exe to install the file(s) after installing mypackage.msi. If they then uninstall mypackage and this removes the support files, the other apps will subsequently fail.
This cannot surely be an uncommon issue as for years Microsoft has promoted the notion of these "shared" files and there are hundreds out there from many vendors - all used and distributed (installed) as part of developer's applications.
A workaround would be install but never uninstall these third-party files. Is there some way I can set this up in AI?
Pete
Good catch! The recommended solution is to use a "merge module" for those common components. A merge module is a pre-built msi-like that can be included into your application. It will contain all the necessary components and files.
You need to ask your component provider for those merge modules. Microsoft provides them for lots of components.
Advanced Installer allows you to include merge modules in your application, although it doesn't allow you to create them yet.
The other solution, with "install & not remove" is also valid, and we will support it from the next version.
Regards,
Cata
You need to ask your component provider for those merge modules. Microsoft provides them for lots of components.
Advanced Installer allows you to include merge modules in your application, although it doesn't allow you to create them yet.
The other solution, with "install & not remove" is also valid, and we will support it from the next version.
Regards,
Cata
-
Pete Furness
- Posts: 16
- Joined: Fri Feb 20, 2004 9:34 am
- Location: SURREY, UK
Thanks, I will include the MSM files.
I think there is still an issue lurking here though...
What if a newer version of "thirdparty.ocx" exists on the target PC before "mypackage.msi" attempts to install it? Surely there must be some way of preventing the older one being installed?
As a supplemental - do merge modules handle this issue?
Pete
I think there is still an issue lurking here though...
What if a newer version of "thirdparty.ocx" exists on the target PC before "mypackage.msi" attempts to install it? Surely there must be some way of preventing the older one being installed?
As a supplemental - do merge modules handle this issue?
Pete
Windows Installer uses file versioning rules when deciding if an installed file should be overwritten or not.
These rules take various factors into account, like time stamp, version, etc. In your example, the newer version will NOT be overriden.
Of course another problem is when apps rely on the older version - welcome to the Windows DLL hell...
Cata
These rules take various factors into account, like time stamp, version, etc. In your example, the newer version will NOT be overriden.
Of course another problem is when apps rely on the older version - welcome to the Windows DLL hell...
Cata
-
Pete Furness
- Posts: 16
- Joined: Fri Feb 20, 2004 9:34 am
- Location: SURREY, UK
I live with DLL hell every day!
If what you said about file versioning issues is correct then in the very first message in this thread I would have expected the second install NOT to install the component if the version was the same... and more importantly not to uninstall it. This is not what is happening, I suspect the overwrite rules (inside AI?) are installing/uninstalling if versions are EQUAL. Can you comment?
Pete
If what you said about file versioning issues is correct then in the very first message in this thread I would have expected the second install NOT to install the component if the version was the same... and more importantly not to uninstall it. This is not what is happening, I suspect the overwrite rules (inside AI?) are installing/uninstalling if versions are EQUAL. Can you comment?
Pete
Advanced Installer only uses the Windows Installer engine and its rules for installations. It does not change them in any way.
What you say makes sense and I do not have an explanation, but the thing is - you are already in an err situation (two different components with the same key and folder) so all bets are off...
Cata
What you say makes sense and I do not have an explanation, but the thing is - you are already in an err situation (two different components with the same key and folder) so all bets are off...
Cata