What are microsoft standards to deliver multiple versions of new file through multiple MSPs patches


We have created two MSP patches both of them delivering one common new file (say A.dll which was not present in base MSI).
In MSP 1 we have created new component for A.dll (set A.dll as key path), MSP 1 installs A.dll properly as per the requirement.

In MSP 2 we created new component again for A.dll (set A.dll as key path), when installed MSP 2 doesn't installs properly, in installation logs i saw following at install validate step :- 
Component: ABC; Installed: Local;   Request: Null;   Action: Null
Component: XYZ; Installed: Local;   Request: Null;   Action: Null
(this is seen for all the components)

We edited MSP 2 and kept component name and GUID of A.dll same as the one we kept in MSP 1 (i.e. now both MSP 1 and MSP2 have same new component added and same file in it but version of file in MSP2 is higher)

Installation of both MSPs was successful now.

Is this the way (Microsoft Standard) to handle new files through MSPs (note :- both MSPs were created using Installshield project (not quickpatch one but normal one).
If yes can someone share the microsoft MSDN url wherein they have mentioned this ?

Problem :-
We have delivered many MSPs like this but in one of the MSPs we missed keeping same component code and name and that MSP is deployed on customer environment.
So we tried to uninstall that particular MSP (in which component code and GUIDs were missed) but uninstallation was not successful and it is uninstalling complete product instead of just one MSP.

We are suspecting this is happening because we delivered same new file with diferrent GUIDs and it is creating conflict internally.

So wanted to know If this is the microsoft standard to deliver new files with same component GUIDs ?
If yes can someone share the microsoft MSDN url wherein they have mentioned this ?

2 Comments   [ + ] Show comments
  • in theory, the GUID should trump the file version. If they were diff guids, same file name, ver and location no probs. if the version is different, then the GUID should be diff too - Badger 7 years ago
  • You mean to say every time you deliver new version of file through MSP, you would change GUIDs of component ?

    Because Ideally microsoft doesn't recommend to deliver same file with different GUIDs (i can understand this is new version)
    Have you read this as an recommendation somewhere ?
    Because this will also result in deletion of old component (which i think microsoft doesn't recommend).

    Also we have delivered many MSPs which updates version file to new version (without changing component GUIDs and it works well)

    Thanks - PPrashant 7 years ago

Answers (1)

Posted by: anonymous_9363 7 years ago
Red Belt
Poor QA, pure and simple.

In your shoes, I'd simply create a new product version with all the correct files in place to bring you back to base, as it were, and have it uninstall the existing version fully by moving the RemoveExistingProducts action higher up the sequence.

  • :) :) Thanks
    I know that's the best solution for this problem and I am trying hard to convince customer for the same.

    But the field scenario is such that this one is becoming practically impossible solution so we are trying hard to understand more technicalities of MSI + MSP, may be with this we might get some workaround for this.
    If not then if i can get Microsoft's recommendations on MSPs (which clearly says that one should deliver same file with same GUIDs) it would help in convincing customer.

    I got one such recommendation on microsoft's MSDN (http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/12/595950.aspx) which says one should not deliver same key file at same location with two different component GUIDs

    Thanks :) - PPrashant 7 years ago
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ