shared dll not removed issue - probable reasoning
Posted: Wed Sep 07, 2011 7:43 pm
We have "TestApp1" placing "appfile.ext" in "c:\apptestdirectory\"
We have "TestApp2" placing "appfile.ext" in "c:\apptestdirectory\" which is marked in InstallAware as a shared dll.
Install both
1. When installing "TestApp1" there is an entry for "appfile.ext" in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\9B6C1D671E5DDBE459DFCBF23C3BB9F2.(Searched for "appfile.ext" and found this).
2. When installing "TestApp2" there is an entry for "appfile.ext" similar to the one above. But in addition since the file is marked shared dll, there is an entry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\ for "appfile.ext" with a value which is equal to the number of installations of that file. And it seems like the Installer searches the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\ root for the number of installations of that file and writes the appropriate number. For this case it is 2.
Uninstall both
3. When uninstalling "TestApp1" it does not go to update the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\, "appfile.ext" key for the number of installations. Sounds correct, as it has not marked the file as shared. And also it correctly removes the entry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\ that it placed while installing.
4. When uninstalling "TestApp2" the entry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\ for the file has value 2. And while uninstalling it seems like the Installer does not search the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\ root for the number of installations of that file and writes the appropriate number. It just decrements it by 1 for the uninstallation it is doing for its own. So as the remaining value is 1, it does not remove the shared dll, even though the dll is not shared by any installed software anymore.
Is it a missed out implementation that is/can be corrected in future releases?
If not, can anyone explain this behavior or point me to a work around?
-Alex
We have "TestApp2" placing "appfile.ext" in "c:\apptestdirectory\" which is marked in InstallAware as a shared dll.
Install both
1. When installing "TestApp1" there is an entry for "appfile.ext" in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\9B6C1D671E5DDBE459DFCBF23C3BB9F2.(Searched for "appfile.ext" and found this).
2. When installing "TestApp2" there is an entry for "appfile.ext" similar to the one above. But in addition since the file is marked shared dll, there is an entry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\ for "appfile.ext" with a value which is equal to the number of installations of that file. And it seems like the Installer searches the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\ root for the number of installations of that file and writes the appropriate number. For this case it is 2.
Uninstall both
3. When uninstalling "TestApp1" it does not go to update the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\, "appfile.ext" key for the number of installations. Sounds correct, as it has not marked the file as shared. And also it correctly removes the entry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\ that it placed while installing.
4. When uninstalling "TestApp2" the entry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\ for the file has value 2. And while uninstalling it seems like the Installer does not search the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\ root for the number of installations of that file and writes the appropriate number. It just decrements it by 1 for the uninstallation it is doing for its own. So as the remaining value is 1, it does not remove the shared dll, even though the dll is not shared by any installed software anymore.
Is it a missed out implementation that is/can be corrected in future releases?
If not, can anyone explain this behavior or point me to a work around?
-Alex