Com LocalServer32条目中的短文件名

我在一个安装程序项目中使用旧的Installshield版本创建了一个组件

MSI中的类表条目创建正确。但是，当安装程序运行注册表中的条目时，LocalServer32将使用一个简短的8.3名称创建

我该怎么做才能使注册表中的条目具有完整的32位长文件名

其背后的问题是：

我的组件尝试使用文件名定位本地化DLL。但是当使用8.3文件名启动组件时，getModuleFileName返回的fielname也是8.3格式。因此，当它只是将DEU附加到名称并将扩展名更改为DLL以定位本地化的DLL时，这有时会失败。我不能修改这个组件。即componentname.exe尝试查找componentnamedeu.dll

---

当我手动注册组件ComponentName.exe-register时，条目都是用完整的长文件名创建的，一切都很完美

查看创建的其余注册表项。我怀疑您会发现类似LocalServer32数据项的东西，而不是带有明显垃圾的密钥。如果是这样，那么会发生的情况是8.3名称不用于定位COM服务器。该垃圾包含ProductCode和组件guid的编码，用于MSI API定位目标文件，必要时调用修复

---

因此，如果这是您看到的，简短的回答是不要使用类表，因为它创建了一个MSI链接来查找目标，而不是文件路径

解决问题的一种方法是使用API将路径转换为文件名的长版本

---

无论参数是缩短的8.3路径还是已经是一条长路径，这都应该有效。

是。正如你所说的。但问题是，我的组件在调用GetModuleHandle时返回短文件名。。。有趣的是，当您使用CreateProcess和短文件名创建流程时，模块名不是长文件名。我决定联系这个模块的代码所有者进行更改。我重复一下，COM不使用这个短名称。它使用编码的ProductCode和组件guid并调用MsiGetComponentPath来定位代码文件。它不会对短文件名调用CreateProcess。它会。我可以在ProjectExplorer中看到它。由于任何原因，使用的文件名都是短文件名。如果使用短文件名启动进程外服务器，GetModuleFilename将返回短文件名。或者让我说：MsiGetComponentPath可能返回一个短文件名，然后我就明白了问题所在。巧合的是，今天的新老事物涵盖了这一问题的另一个方面：有趣的巧合，是的，COM并不是唯一使用达尔文描述符来定位实际文件的地方。除了旧的新东西外壳扩展，它们也在MSI快捷方式中。它们都对Darwin描述符进行解码，并调用MsiGetComponentPath或等效程序来查找要加载的实际代码文件。@xMRi，那么您控制哪些部分呢？你把它叫做你的组件。我的组件和代码所有权是主要的应用程序和安装程序。另一个程序员拥有组件的代码。问题现在已经解决了。程序员现在使用GetModuleFileName，然后在上面调用GetLongPathName并使用他检索到的名称。