支持仅限此用户和本地计算机设置
我有一个应用程序必须支持根据所需的“安装”类型修改某些注册表数据。目前，我可以通过硬编码来获取提升并对整个本地计算机进行更改，但这远非理想状态，我还想支持每用户安装。我可以对其进行硬编码，但随后我会丢失本地计算机的内容。准确地说，所讨论的更改涉及文件关联更改、COM 内容等。
如何正确支持这两种使用场景？ 目前，我对各种关联使用一组开/关复选框。
- 我是否应该更改此含义，例如，我的应用程序目录中存在的 MachineInstall 文件，如果不假定用户安装？
- 有人可能想为整个机器做一些事情，而只为用户做一些事情，这是一个预期/有效/任何用例吗？ （例如两者的混合。）
- 或者我应该更改整个用户界面，远离复选框并移动到某种组合框“无/用户/本地”？话又说回来，我认为一旦涉及多个用户和组合，这可能会产生某种破坏。
为了表明这一点，我个人希望所讨论的应用程序对计算机上的每个人都有其用途，因此倾向于将本地计算机作为“默认”，如果这有什么区别的话。
我可能对这个问题想得太多了，所以非常感谢任何和所有的意见。 :)
PS
现在，有人可能会说“不要从应用程序中执行所有这些操作，而是从安装程序中执行”。他们可能有道理，但要点是允许从应用程序内轻松更改这些设置。最重要的是，我没有使用 .MSI 安装包，因为它们使使用 32/64 位特定可执行文件成为一场灾难，需要合并模块，根据情况生成其他 MSI，等等（上次我忘记了详细信息）深入研究并忘记了这件事）。我没有这些知识，也没有时间学习 MSI 安装的所有复杂性，所以就我而言，它已经结束了。首先，我的应用程序完全能够在不存在任何这些注册表项的情况下运行，这是设计使然。在某种程度上，人们可能会将它与 Sysinternals 的 Process Explorer 进行比较，它不需要安装程序，但如果用户愿意，可以解压缩并接管任务管理器等，不会出现任何问题，或者只是独立运行。
I have an application that has to support modifying some registry data depending on the kind of 'installation' that is desired. At present, I have no problems hard-coding to either get elevation and do the changes to the entire local machine, but it is far from nice as ideally, I would also like to support per-user installations. I could hardcode that, but then I lose the local-machine stuff. To be precise, the changes in question involve file association changes, COM stuff etc.
How can I properly support both usage scenarios? Currently I use a set of ON/OFF checkboxes for the variety of associations.
- Should I change this meaning on, for example, a MachineInstall file existing in my apps directory, and if not assume User install?
- Is it an expected/valid/whatever usecase to say that someone might want to do some things for the entire machine, and some things only for the user? (E.g. mixing of the two.)
- Or should I change the entire UI, move away from checkboxes and move to some sort of combobox going 'None/User/Local'? Then again, I think this might have some sort of breakage once you involve multiple users and combinations.
To give an indication, I personally expect the application in question to have its uses for everyone on a computer and as such lean towards the Local-Machine as a 'default', if that makes any sort of difference.
I am likely overthinking the matters quite a bit, so any and all input is very much appreciated. :)
P.S.
Now, someone is probably going to say 'do not do all that stuff from your app, do it from the installer instead'. And they probably have a point, but the point is to allow easy changing of these settings from within the application. To top it off, I am not using .MSI install packages because they make working with 32/64-bit specific executables a disaster requiring merge modules, spawning other MSI's depending on the situation, and so forth (I forgot the details last time I dug into it and forgot about the matter). I don't have that knowledge, nor the time to learn all the intricacies of MSI installations, so it is out for as far I am concerned. To boot, my application is perfectly capable of functioning without any of those registry entries being present, and that is by design. In a way, one might compare it to be like Process Explorer from Sysinternals, which does not require an installer, but can be unzipped and take over the task manager etc without a problem if a user wants, or simply run stand-alone.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论