Best practice for removing an installed, registered DLL

[klmag]

I have DLLs that were installed with version 1.0.0 of my application. I enabled these Installation/Uninstallation Properties:

Register as Shared File
Register as OCX/DLL/EXE/TLB
Remove on Uninstall

I also have implemented Web Updates. My "Full Installer" installs some required drivers, installs VC++ Redistributable Package. My "Update Installer" doesn't include the larger files that are required to run my application that were installed in the "Full Installer" which is an effort to reduce download size & bandwidth usage from the web.

Now I want to release version 1.0.1 of my application (both Full and Update). This time around, I removed some of the aforementioned DLLs that aren't needed any longer.

What is the best way to remove those files completely?

My idea was: check if the file/DLL exists; if it does, "uninstall" the file. I'm assuming I would have to "undo" the installation properties manually in the script, for each file.

The idea I personally shot down was uninstall the application, then re-install the update--that would defeat the purpose of a small sized Update Installer.

My main objective is to have no files (my application requires) remaining on the machine or registry entries in the registry, after running the uninstaller that was installed with the Update Installer.

[linder]

Hello,

Yes, your idea is correct! Just "undo" the installation properties manually in the script, for each file, during the 1.0.1 installation process.

Friedrich

[klmag]

Thanks for the response!

1. How do I properly undo the "Register as Shared File" manually?
2. To unregister, is it a simple "regsvr32 /s /u [file path]?"
3. Do I need to check if a file exists before trying to delete it, or is there a silent remove?

[linder]

Hello,

To handle the Shared File feature in Windows, you have to decrement the counter for you file in the following registry key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Sha redDlls\c:\yada\yourfile.dll

You can use the "Get Registry Key Value..." (to read) and the Edit Registry..." (to write) script functions to handle this.

If the counter is 0 (after decrementation), you have to:

1. Unregister the OCX file (you can use the "Unregister File Operations" -> "Unregister OCXs/DLLs/EXEs/TLBs file immediately" script function.

2. Remove the above mentioned key value name (Shared File counter).

3. Delete the file (using the Delete File(s)...) script function. No need to check if the file exists before trying to delete it.

Does this help?

Friedrich

[linder]

BTW, I think we'll add a new "Delete Shared File..." function to the next SetupBuilder update to automate this process.

Friedrich

[klmag]

Great information!

I was going to suggest a feature request after I asked the question, which would automate everything because, why not, right?!

It sounds like it should go pretty smoothly; if not, I'll update the post :)

Thanks again!

Lastly, we have been 100% satisfied with the capabilities of SetupBuilder 8 and the timely, helpful support Lindersoft provides! Keep up the good work!

[linder]

Thank you SO MUCH for you kind words :)

If there is any problem (or if you have more suggestions), just let me know. And the new function will definitely be available in the next SB update.

Friedrich

[klmag]

I installed my application on x64 Win 8 machine. After the .DLLs (32-bit application) are registered as shared, they show up in:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ Windows\CurrentVersion\SharedDlls

How should I handle that in the case this could be installed on a x86 or x64; the problem being the Wow6432Node in the key. I assume that wouldn't be there on a x86 machine.

[linder]

Hello,

You always specify HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\SharedDlls and never hard-code the "Wow6432Node" item. Redirection is handled for you behind-the-scenes.

Friedrich

[klmag]

That seemed to have worked great.

What I did notice is that if the reference count in the SharedDll key is >1, and I uninstall the application--remember Register as Shared File and Remove on Uninstall were both checked--the files still get removed from the INSTALLDIR.

Do I need to uncheck "Remove on Uninstall" and manually check the reference count in the script to see if its safe to delete the files? It would be nice if that automatically happened because adding cases for 120 files would get ugly.

[linder]

Hello,

Please see attached screenshots (Windows 10 Enterprise Edition x64, latest TP build). Two projects make use of the same shared DLL. After running both setups, the shared counter for the file SBKERNEL.DLL is "2". After uninstalling one project, the shared counter is "1" and the file is still there. If it is "0" then the uninstaller removes the registry key and the file.

Does this help?

Friedrich

[klmag]

I must be doing something wrong. Please see attachment.

I am installing my COM dlls in %COMMONFILESIDIR%\MyCompany\Location\.

When I "regsvr32 -u" manually the count decrements by one, so its not happening inside COM code itself.

[klmag]

I think I went over file size limit. Here:

http://i.imgur.com/bfdWfA9.jpg

[linder]

Hello,

I am afraid I don't understand, sorry :( What does "regsvr32 -u" have to do with the SharedDll counter and with the deleted file(s)?

Friedrich

[linder]

BTW, an installer does not use "regsvr32 -u" because it calls the Windows API directly (Register as OCX checkbox).

Friedrich

[klmag]

Sorry for the confusion.

I thought calling regsvr32 -u decrements the reference count but I just found out it doesn't!

Either way, my files are still being deleted on uninstall even went reference count > 1. Would you like me to send installers? Do you need .sb8 files also?

[klmag]

I figured it out! Because v2 (update from v1) marked the file as shared DLL as well as in v1, the count was incremented to 2. If I manually increment the count to 3, and uninstall the application, the entry is then only 1. Awesome, SB8 keeps track of the amount of times the number is incremented!

Will changing the upgrade GUID or anything cause the uninstaller to lose this reference count?

[linder]

Perfect, thank you for the update! :)

No, you can change the GUID and the uninstaller will NOT lose this reference count.

Friedrich

[linder]

I was going to suggest a feature request after I asked the question, which would automate everything because, why not, right?!

New function added to the internal SetupBuilder version. It will handle it automatically. This will be available in the next update.

Thanks again for your suggestion.

Friedrich