从 Windows 卸载时如何从其他用户帐户中删除 ProgID? [英] How to delete ProgIDs from other user accounts when uninstalling from Windows?

查看:33
本文介绍了从 Windows 卸载时如何从其他用户帐户中删除 ProgID?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在研究现代 Windows C++ 应用程序应如何在 Windows 中注册其文件类型"(参见 解决方案

我刚刚意识到:MS 希望我们做的是让每个用户覆盖文件映射本身 - 即 .foo -> 什么?不要创建任何 progID,它应该只由安装程序创建,它们会被卸载程序删除,所以没有悬挂的 ProgID" - 只有映射到丢失的 ProgID 的悬挂文件映射",MS 明确声明是可以的.

安装前:HKCR\.txt -> HKCR\txtfile(全局)

安装后:HKCR\.txt -> HKCR\MyEditor.text.1(全局)

用户决定将 .txt 文件映射到 TextPad:HKCU\Software\Classes\.txt -> HKCR\TextPad.txt(仅限该用户,全局还是.txt->MyEditor.text.1)

卸载后:HKCR\.txt x-> HKCR\MyEditor.text.1(全局,但是key HKCR\MyEditor.txt.1已经被删除了)

覆盖其值的用户仍然没有问题,因为无论他们个人的 .txt 点副本是否有效,无论哪种方式,Microsoft 都会处理.

我希望能帮助别人...

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)

解决方案

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...

这篇关于从 Windows 卸载时如何从其他用户帐户中删除 ProgID?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆