Windows 应用程序注册表设置和指南 [英] Windows application registry settings and guidelines

问题描述

因为我一直在学习 WiX 来编写安装程序，所以我从文档和教程中学到了很多如何在安装过程中设置程序以及设置或读取注册表值的方法.但是，上述文档和教程中的注册表设置并没有说明这些设置的要求是什么.

作为一个具体示例，我有一个用于简单应用程序的 WiX 安装程序，其中 InstallScope 设置为 perMachine.我想在我的 WiX 安装程序中添加一个注册用户"对话框.我找到了一个示例，它允许用户输入他们的姓名、组织和注册密钥.这些设置为 WiX 预定义属性:分别为 USERNAME、COMPANYNAME 和 PIDKEY.当这些经过验证后，WiX 会将这些写入到以下注册表文件夹中:

HKLM >软件 >微软窗口 >当前版本>安装程序用户数据S-1-5-18 >产品 >{GUID} >安装属性

我一直在进行大量研究，试图找到以下问题的答案，但一直没有找到答案.

1. 在安装最简单的 Windows 应用程序时，需要设置哪些注册表项的最低要求(或至少是最低 Microsoft 准则)是什么?我知道这在某种程度上取决于安装是针对所有用户(机器)还是针对特定用户，因此会有两种不同的答案.

2. 简单的应用程序信息应该保存在注册表中的标准位置在哪里?

3. 为了满足 #1 的准则/要求，WiX 总是在幕后创建哪些注册表设置而没有明确的 XML 条目来使它们发生?

4. 一旦设置了某些注册表项，如上面给出的示例，应用程序如何使用注册表 API 正确定位它们?具体来说，例如，如果安装后，我希望我的应用程序能够读取注册用户信息，它是否真的必须知道并打开如上所示的整个密钥，或者是否有处理其中一部分的 Windows API 调用?

我确实在 MSDN 中找到了一些很有前景的信息，在一篇题为

从注册表数据库中检索 MSI 属性所需的所有信息都应在该示例文件 (wilstprd.vbs) 中，但以下是我在拥有它后改编的快速模型可用(我认为这是我改编的 Phil 的样本).它只是一个没有任何错误处理的最小样本.它只是将一些核心 MSI 属性输出到所有已安装 MSI 文件的文本文件中.

复制脚本并粘贴到桌面上的 *.vbs 文件中，然后尝试通过双击运行它.您的桌面必须是可写的，或者您可以使用任何其他可写位置.输出到 msiinfo.csv(显然在 Excel、记事本或任何其他查看器中打开以获取逗号分隔值).这是一个糟糕的脚本，它没有错误处理，也没有在属性值中转义任何嵌入的逗号，但它只是用作 MSI API 的一个简短示例:

Set fso = CreateObject("Scripting.FileSystemObject")设置输出 = fso.CreateTextFile("msiinfo.csv", True)Set installer = CreateObject("WindowsInstaller.Installer")On Error Resume Next ' 忽略所有错误output.writeline("Product Code,Product Name,Version") ' 列标题' 为每个安装的 MSI 包输出 3 个核心的内置 MSI 属性对于每个产品在 installer.ProductsEx("", "", 7)产品代码 = 产品.产品代码name = product.InstallProperty("ProductName")version=product.InstallProperty("VersionString")output.writeline (productcode & ", " & name & ", " & version)下一个输出.关闭MsgBox "导出完成，请打开 msiinfo.csv"

<小时>

最后，问题 1 &3 - 注册所需的最低属性是什么?诚实的回答是我不知道.我不确定.

这只是一个暂定答案，但 MSI SDK 示例脚本 wilstprd.vbs 会检索以下 MSI 属性.我认为这意味着这些总是写入 MSI 数据库 - 其中一些似乎总是返回一个空字符串.因此，它们是内置 MSI 属性.

ProductCode、Language、ProductName、PackageCode、Transforms、AssignmentType、PackageName、InstalledProductName、VersionString、RegCompany、RegOwner、ProductID、ProductIcon、InstallLocation、InstallSource、InstallDate、发布者、LocalPackage、HelpLink、HelpTelephone、URLInfoAbout、URLUpdateInfo

其中一些属性至关重要并且来自 MSI 数据库文件本身，例如产品代码、产品名称、语言、PackageCode、VersionString.如果没有设置这些值，我认为无法安装 MSI.据我所知，所有这些都应该由 WiX 编译包设置.

其他属性的设置取决于通过 msiexec.exe(命令行)执行安装的方式.这包括转换(在安装命令行应用的转换列表)、AssignmentType(MSI 是按机器安装还是按用户安装)、InstallSource(安装的 MSI 的源位置)、InstallDate(安装或进行了修改).

转换是在安装时应用于 MSI 的小数据库片段.它们用于在不更改原始文件的情况下修改原始 MSI.这里是使用转换和应用它们的说明和/或命令行中的属性值.

最后，一些属性似乎经常丢失并返回空白，例如 RegCompany、RegOwner、HelpLink、HelpTelephone、URLInfoAbout、URLUpdateInfo.我认为这些可能需要手动添加到属性表中(或者更确切地说是作为属性添加到您的 WiX 源文件中).

<小时>

完全偏离主题，但你问了所有正确的问题，我认为你只需要正确的信息来源(而不是我可能过度解释).

如果这是不礼貌的行为，我深表歉意 - 但这应该包括各种来源，如果人们在此处找不到答案，这些来源实际上可能会有所帮助.如果不合适，我很乐意将其删除.

在了解新技术时，我总是尝试通过帮助文件和基本示例来查找SDK 信息.然后我寻找真实世界的样本，最后我寻找信息来源和博客来寻求建议和阅读(本质上弄清楚什么不该做，而不是什么去做).以下是我最喜欢的 MSI/WiX 信息来源 - 自助链接:

权威来源圣经"帮助文件:

• MSI SDK:msi.chm
• WiX 帮助文件:WiX.chm
• DTF 帮助文件(包含在 WiX 中):DTF.chm、DTFAPI.chm

DTF 是整个 MSI API 的 .NET 包装器.它设计得非常好，可以很容易地使用 C# 和其他 .NET 语言访问 MSI 文件和 MSI 信息.它作为 WiX 的一部分安装.

在线 WiX 资源:

• WiX 文档主页
• WiX 参考手册
• WiX 教程

查找一般部署信息:

• http://www.installsite.org
• http://www.itninja.com/

提出部署问题:

• http://forum.installsite.net
• http://www.itninja.com/question
• http://www.stackoverflow.com(显然)
• http://community.installshield.com/
• http://www.advancedinstaller.com/forums/

博客:

• https://www.joyofsetup.com/
• http://robmensching.com/blog/(旧版:https://blogs.msdn.microsoft.com/robmen/)
• https://blogs.msmvps.com/installsite/
• http://blog.deploymentengineering.com/
• https://blogs.msdn.microsoft.com/astebner/立>

我认为这应该是一个部署资源的平衡清单"，但很多人可能已经忘记了.

<小时>

As I have been learning WiX to write an installer, I've learned a lot from documentation and tutorials how to setup a program during install and set or read registry values. However, the registry settings in said documentation and tutorials is done without explanation for what the requirements are for such settings.

As a specific example, I have a WiX installer for a simple application with InstallScope set to perMachine. I wanted to add a "registered user" dialog to my WiX installer. I found an example which allows the user to enter their name, organization, and a registration key. These are set to the WiX pre-defined properties: USERNAME, COMPANYNAME, and PIDKEY, respectively. When these are validated, under the hood, WiX writes these out to the following registry folder:

HKLM > Software > Microsoft > Windows > CurrentVersion > Installer > UserData > S-1-5-18 > Products > {GUID} > InstallProperties

I've been doing a lot of research trying to find the answer to the following questions and have not been able to find the answers.

1. What are the minimum requirements (or at least minimum Microsoft guidelines) for what registry entries need to be set when installing the simplest Windows application? I know that this depends somewhat whether the install is for all users (machine), or specific users, so there would be two different answers.

2. Where are the standard locations that simple application information is supposed to be kept in the registry?

3. In order to meet the guidelines/requirements of #1, what are the registry settings that WiX always creates under the hood without explicit XML entries to make them occur?

4. Once certain registry items are set, as in the example given above, how does the application locate them properly using the registry API? Specifically, for example, if once installed, I want my app to be able to read the registered user information, does it literally have to know and open the entire key as shown above, or is there a Windows API call that handles part of that?

I did find some promising looking information in the MSDN, in an article entitled, Application Registration, but I'm having trouble correlating the specifics of that article with what WiX does with the registry for an install. Specifically, for example, they suggest using HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER > SOFTWARE > Microsoft > Windows > CurrentVersion > App Paths > ... but on my system (running Windows 10) that key doesn't even exist. So other apps aren't even using it. This leads back to my question #1.

解决方案

I think Phil has answered most of your questions, let me see if I can add something to issue 4. Some tentative answers to issue 1 and 3 towards the end. And issue 2 - perhaps see the list of registry locations just below.

If I understand correctly, you want to access the "standard properties" written to the registry during the installation via the proper APIs so you don't need to read the registry locations you speak of directly. In essence you want to go through the correct APIs.

Thank God someone makes the effort to figure this out, way too many people hack the registry directly. Never go down that road.

---

With regards to issue 2. The Windows Installer database is stored in several registry locations, here are some of them:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer
• HKCR\Installer
• HKCU\Software\Microsoft\Installer
• Please add items here if you got any, I know there are more locations than this

Everything found under these keys is essentially an implementation detail as Phil has explained. Nothing should be written here, and as you suspect nothing should be read from here "manually" (directly).

Maybe I misunderstood the question? Perhaps what you want is to know where to store your own, custom MSI properties reliably? If you ask me, I would just store them in either:

• HKLM\Software\YourCompany\YourApp\MajorVersion [List of values here]
• HKCU\Software\YourCompany\YourApp\MajorVersion [List of values here]

You can make any number of such custom properties, and you simply use a registry element in WiX to write the value of the property to the registry. You refer to the value as [PROPERTYNAME] in the registry tag to write the value of the property to the specified registry key / value.

• How To: Read a Registry Entry During Installation
• How To: Write a Registry Entry During Installation

Your application can then read the information back with ease using standard Win32, .NET or even COM APIs.

---

Now issue 4 - retrieving built-in MSI property values from the registry:

If you want to retrieve standard, built-in MSI properties from the registry (in other words, not your own, custom properties), you should go through the proper API, since the location in the registry will be a "moving target" when you upgrade your application using an MSI major upgrade (the product code is part of the registry path, and using a major upgrade the product code will change) - so do not read directly from sub keys of: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18.

So, in order to access information in MSI database files directly (from actual MSI database files) OR to retrieve information from installed packages on your system (from the registry), you can use the MSI API - in other words the Windows Installer Win32 API which also provides a COM layer on top of it accessible from scripting languages. So in essence you have:

1. C/C++ style installer functions (Win32 calls usually used from C++)
2. COM automation
   • Essentially a COM layer on top of the installer functions
   • You can use VBScript, JavaScript, or any Active Scripting languages to access it.
3. Third alternative: DTF - a .NET wrapper around the Win32 MSI SDK (details below, and on serverfault.com). Allows you to efficiently access the MSI SDK from .NET languages such as C# without any COM Interop clunk.

The MSI SDK: Do you have msi.chm help file readily available? This is the MSI Bible. It is your one-stop location for all things MSI (you probably already have it, I think it is installed with WiX) - and you will find the documentation for accessing the MSI API here. If you don't have the file, but have Visual Studio installed, just search for it and add a shortcut to your desktop or something like that. Or look for it in your WiX installation folder. You can also find the info online on MSDN, but it is much faster using the local file. And you get a sense of "completeness" when you are dealing with a file instead of the "endless web".

As part of the MSI SDK there is a sample COM automation VBScript which shows how to retrieve product information (product properties) for an installed MSI package. It is called wilstprd.vbs - there is a whole family of such sample VBScript for various MSI related tasks. I am almost certain this is not included with WiX (perhaps it should be?), and it is NOT part of the MSI SDK help file msi.chm.

If you have Visual Studio installed, the Windows SDK should also be installed. Just search for wilstprd.vbs and you should find it in several locations (x86, x64 versions - no file content difference). You can start your search in %SystemDrive%\Program Files (x86)\Windows Kits if you have a default installation.

You can run this script like so (using cmd.exe or powershell.exe):

cscript .\wilstprd.vbs "{A645BC30-D32A-408B-B964-C190C9056D7A}"

This will produce a list of property values from the installed MSI:

All the information you need to retrieve MSI properties from the registry database should be in that sample file (wilstprd.vbs), but below is a quick mock-up that I adapted since I had it available (I think it was a sample from Phil I adapted). It is just a minimal sample without any error handling. It just outputs some core MSI properties to a text file for all installed MSI files.

Copy the script and paste into a *.vbs file on your desktop, and try to run it by double clicking. Your desktop must be writable for you, or you can use any other writable location. Output is to msiinfo.csv (obviously open in Excel, Notepad or any other viewer for comma separated values). This is a terrible script in the sense that is has no error handling, and it doesn't escape any embedded commas in the property values, but it is just intended as a short example of the MSI API in action:

Set fso = CreateObject("Scripting.FileSystemObject")
Set output = fso.CreateTextFile("msiinfo.csv", True)
Set installer = CreateObject("WindowsInstaller.Installer")

On Error Resume Next ' Ignore all errors

output.writeline ("Product Code,Product Name,Version") ' Column headers

' Output 3 core built-in MSI properties for each installed MSI package
For Each product In installer.ProductsEx("", "", 7)
   productcode = product.ProductCode
   name = product.InstallProperty("ProductName")
   version=product.InstallProperty("VersionString")
   output.writeline (productcode & ", " & name & ", " & version)
Next

output.Close

MsgBox "Export done, please open msiinfo.csv"

---

And finally, issue 1 & 3 - what are the minimum properties required for registration? The honest answer is that I don't know. I am not sure.

This is then only a tentative answer, but the MSI SDK sample script wilstprd.vbs retrieves the following MSI properties. I assume this means that these are always written to the MSI database - some of them seem to always return an empty string. They are hence built-in MSI properties.

ProductCode, Language, ProductName, PackageCode, Transforms, AssignmentType, PackageName, InstalledProductName, VersionString, RegCompany, RegOwner, ProductID, ProductIcon, InstallLocation, InstallSource, InstallDate, Publisher, LocalPackage, HelpLink, HelpTelephone, URLInfoAbout, URLUpdateInfo

Some of these properties are crucial and come from the MSI database file itself such as Product Code, ProductName, Language, PackageCode, VersionString. I don't think an MSI can be installed without these values set. All should be set by a WiX compiled package, to the best of my knowledge.

Other properties are set depending on how the installation was performed via msiexec.exe (command line). This includes Transforms (list of transforms applied at the installation command line), AssignmentType (whether MSI is installed per machine or per user), InstallSource (the source location for the installed MSI), InstallDate (short DateTime in string form for when install or modify was performed).

Transforms are little database fragments applied to an MSI at install time. They are used to modify the original MSI without changing the original files. Here is a description of using transforms and applying them and / or property values at the command line.

Finally some properties seem to often be missing and return blank such as RegCompany, RegOwner, HelpLink, HelpTelephone, URLInfoAbout, URLUpdateInfo. These may need to be manually added to the property table I believe (or rather added as properties in your WiX source file).

---

Completely off topic, but you ask all the right questions, and I think you just need the right information sources (instead of me over-explaining things perhaps).

I apologize if this is poor etiquette - but this should include all kinds of sources that may actually help people if they can't find answers here. I am happy to delete this if inappropriate.

When finding my feet with new technologies I always try to find the SDK information with help files and hopefully basic samples. Then I look for real-world samples and finally I look for information sources and blogs to ask for advice and read (in essence figure out what not to do, more than what to do). Here are some of my favorite information sources for MSI / WiX - links for self-help:

The definitive sources the "bible" help files:

• The MSI SDK: msi.chm
• The WiX help file: WiX.chm
• The DTF help files (included with WiX): DTF.chm, DTFAPI.chm

DTF is a .NET wrapper for the whole MSI API. It is extremely well designed and makes it easy to access MSI files and MSI information using C# and other .NET languages. It is installed as part of WiX.

Online WiX resources:

• WiX Documentation Home
• WiX Reference Manual
• WiX tutorial

Finding general deployment information:

• http://www.installsite.org
• http://www.itninja.com/

Asking deployment questions:

• http://forum.installsite.net
• http://www.itninja.com/question
• http://www.stackoverflow.com (obviously)
• http://community.installshield.com/
• http://www.advancedinstaller.com/forums/

Blogs:

• https://www.joyofsetup.com/
• http://robmensching.com/blog/ (old: https://blogs.msdn.microsoft.com/robmen/)
• https://blogs.msmvps.com/installsite/
• http://blog.deploymentengineering.com/
• https://blogs.msdn.microsoft.com/astebner/

I think that should be a "balanced list" of deployment resources, but many may have been forgotten.

---

这篇关于Windows 应用程序注册表设置和指南的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！