What are microsoft standards to deliver multiple versions of new file through multiple MSPs patches
Hi,
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
Answers (1)
Please log in to answer
Posted by:
anonymous_9363
9 years ago
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.
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.
Comments:
-
:) :) 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 9 years ago
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 9 years ago