Dealing with features whose dependencies duplicate dlls.
I am trying to package a .NET application by running a dependency check and creating folders for each feature. Some of the features share dll's. Eg. Feature A and Feature B may include xxx.dll. Therefore when the full feature set is installed (into one application directory) some dll's are being overwritten several times. At this point a count appears in the shared area of the registry. However, when I uninstall everything, the counts are deleted but PreviouslyPinned=1 is still set in the log file. Although the counts are 0, the duplicated dll's are not uninstalled.
Well I finally found the cause of my problem after much struggling and searching of this forum.
Just to reiterate, here is my situation:
I have Features A and Feature B both of which contain xxx.dll and I want to install both into the same destination directory. (meaning that one feature will overwrite the other's dll). In Installshield I have a 1-1 relationship between the feature and the folder containing the dlls.
This is what Installshield does by default:
If you use the Add Folders button in Installshield (with dynamic folder linking or otherwise) it will create a component for each dll. e.g. xxx.dll xxx.dl1 etc. If you validate this against the Full MSI Validation suite you get lots of ICE30 errors and running an uninstall fails to remove the 'duplicate' files.
...and my solution
Using the direct edit tool I modified the FeatureComponents table to point each Feature to the single component e.g. (xxx.dll) and removed the 'duplicates' from the Components table (xxx.dll1). Now, the uninstallation works as it should.
I can do all of this manually, however ideally I want to use the dynamic file linking feature of 'Add Folders'. So the question is, how do I change Installshield's default behaviour to match what I want? i.e. Create one component for the first time a dll is seen (i.e. in Feature A), then afterwards (Feature B, C etc) assign a reference to the existing component? Do I need to write a tool to automate tidying up the MSI database afterwards? Surely the default behaviour of Installshield should always produce a valid MSI regardless of the situation.
