CODEWITHSUNDEEP
c++winapiwindows-shellfile-type
Mordachai
Mordachai

Reputation: 9662

How to delete ProgIDs from other user accounts when uninstalling from Windows?

I've been investigating "how should a modern windows c++ application register its file types" with Windows (see C++: How do I correctly register and unregister file type associations for our application (programatically)).

And having combed through the various MSDN articles on the subject, the summary appears to be as follows:

  1. The installer (elevated) should register the global ProgID HKLM\Software\Classes\my-app.my-doc[.version] (e.g. HKLM\Software\Classes\TextPad.text)
  2. The installer also configures default associations for its document types (e.g. .myext) and points this to the aforementioned global ProgID in HKLM.
    NOTE: a user interface should be provided here to allow the user to either accept all default associations, or to customize which associations should be set.
  3. The application, running standard (unelevated), should provide a UI for allowing the current user to set their personal associations as is available in the installer, except that these associations are stored in HKCU\Software\Classes (per user, not per machine).
  4. The UN-installer is then responsible for deleting all registered ProgIDs (but should leave the actual file associations alone, as Windows is smart enough to handle associations pointing to missing ProgIDs, and this is the specified desired behavior by MSDN).

So that schema sounds reasonable to me, except when I consider #4: How does an uninstaller, running elevated for a given user account, delete any per-user ProgIDs created in step #3 for other users?

As I understand things, even in elevated mode, an uninstaller cannot go into another user's registry hive and delete items? Or can it? Does it have to load each given user hive first? What are the rules here?

Thanks for any insight you might have to offer!

EDIT: See below for the solution (My question was founded in confusion)

Upvotes: 1

Views: 1152

Answers (2)

Mordachai
Mordachai

Reputation: 9662

I just realized: What MS wants us to do is to have per-user override the file mapping itself - i.e. .foo -> what? NOT create any progIDs, which should only be created by the installer, which are deleted by their uninstaller, so no "dangling ProgIDs" - only "dangling file mappings" which map to a missing ProgID, which MS explicitly states is OK.

Before install: HKCR\.txt -> HKCR\txtfile (global)

After install: HKCR\.txt -> HKCR\MyEditor.text.1 (global)

A user decides they want to map .txt files to TextPad instead: HKCU\Software\Classes\.txt -> HKCR\TextPad.txt (this user only, globally still .txt->MyEditor.text.1)

After uninstall: HKCR\.txt x-> HKCR\MyEditor.text.1 (global, but the key HKCR\MyEditor.txt.1 has been deleted)

And the one user who overrode their value is still okay because wherever their individual copy of .txt points is either valid or not, either way, Microsoft handles it.

I hope that helps others...

Upvotes: 1

Thomas
Thomas

Reputation: 181745

As far as I know, settings in other user accounts are usually just left there. This is not limited to file type associations.

It would be nearly impossible to delete the settings from all user accounts, because some might be roaming profiles on a domain that is not currently connected, or that the local administrator has no access to.

Upvotes: 1

Related Questions