>情况：
我在 C# 中创建了一个 DLL，它使用 COM 运行Process.Start以通过 Web 浏览器运行程序。我使用VS2010的内置部署项目创建了一个MSI。我为此 DLL 中的对象指定 Guid 属性，但从不指定位置。当我运行 MSI 并选择为"Just Me"安装时，注册表项按预期在 HKCU （current_user） 中创建。我需要它为所有用户运行，因此当我运行 MSI 并选择为"所有人"安装时，注册表项也会按预期在 HKLM （local_machine） 中创建。无论哪种方式，一旦 MSI 安装了 DLL，使用 DLL 的内部网 Web 应用程序分别适用于我作为管理员 （current_user） 和所有用户 （local_machine）。
但是，在我公司的主要 IT 部门内部，我们无法创建自己的 MSI。我们必须将请求和我们的DLL/TLB文件发送给唯一功能是为供应商/内部开发人员创建MSI的人。当我手动运行他的 MSI 并选择为"每个人"安装时，它再次按预期工作。
问题：
但是，MSI 需要作为部署的软件自动运行，发生这种情况时，注册表项仅在 HKEY_CURRENT_USER 中创建，因此当测试用户尝试使用该功能时找不到它们。他说ALLUSERS属性设置为 1，所以这应该有效。此外，当我要求他将它们安装到正确的位置（local_machine）时，他坚持认为我需要在我的 DLL 中进行这些更改，因为"MSI 文件不会创建注册表项，它在安装过程中来自 DLL"。根据我在网上阅读的各种文章，MSI 通常指定在注册表中创建这些密钥的位置。
问题（也适用于TL;DR）：
他断言我需要在我的 DLL 中指定注册表位置是否有任何道理？如果是这样，如何以编程方式指定这些键默认转到HKLM？现在，我所做的只是指定ComVisible，ClassInterface，Guid，ProgId和ComDefaultInterface。我从未指定过位置，除了MSI中的"所有人/只有我"。我对 COM 对象相对较新，并且在注册表中弄乱了我自己的创作，所以我不想跳到他的喉咙里说我不能做他应该做的事情。
谢谢！
正确理解你的问题，你的意思是：
- 您不能使用自己的 MSI 在网络中部署 DLL，
- 您无法控制 IT 部门在他们提供的 MSI 中打包和部署 DLL 的方式，
- 您希望 IT 注册 DLL 的方式与您的完全相同。
在这种情况下，我建议创建一个合并模块（MSM）而不是安装包（MSI）。将所有设置逻辑（文件、注册表项、自定义操作等）放在合并模块中。
然后围绕该合并模块编写一个简单的 MSI shell，供您自己使用，并将合并模块提供给您的 IT 部门，要求他们将其集成到自己的安装包构建过程中。
有一个实用程序称为"regsvr.exe"。 它在System32中，您应该能够在命令行上仅使用"regsvr"调用它。 因此，调用是：
prompt> regsvr [dllname]
其中 [dllname] 是 DLL 文件的名称（如果相对名称在当前目录中，则相对名称很好）。
在 Windows Vista 和 7 上，此命令必须以管理权限显式运行（即您必须使用管理权限运行 cmd.exe），仅仅作为管理员是不够的。
要使用管理员权限运行命令提示符，请打开开始栏，在搜索字段中键入"cmd"，然后使用 [CTRL][SHIFT][ENTER] 启动，并接受 UAC 提示符（如果出现）。 （您可以通过这种方式以管理员身份运行任何程序。