将显示语言更改为土耳其语结果为“80070002” COM 互操作中的错误
我完全被难住了，所以我正在寻找的是一系列猜测。或者也许有人真的知道发生了什么事。
我有一个用 VB6 编写的程序，它已将每个用户界面元素字体设置为“MS Sans Serif，7 点”，以创建英语/土耳其语本地化。本地化字符串被编译到 VB6 EXE 中，并且有自定义代码可以在语言之间进行热切换。
该程序通过 COM 到达 .NET DLL 程序集，该程序集带有一个“tr”卫星程序集，因此它也在混合中。
使用干净的测试系统，将显示语言（不是非 unicode 设置，另一种更通用的设置）设置为“英语”，软件运行没有问题。
当设置为土耳其语时，.NET Interop 系统返回“运行时错误 '-2147024894 (80070002)' -- 自动化错误 -- 系统找不到指定的文件。”一旦（看起来）.NET DLL 被调用。 （编辑：这可能不是 .NET DLL。我已经向 Microsoft 发起了一个事件，以获取深度跟踪的更多信息。）
因为这是一个干净的系统测试，所以没有安装诊断工具，而是使用 Sysinternals 进行跟踪ProcMon 未能向我展示我能识别的东西。
问题是：这是追踪我的晦涩的小“文件未找到”错误的正确工具吗？有更好的工具吗？我应该寻找什么？
但最根本的是，有谁知道当显示语言发生变化时会发生什么变化，这会导致 VB6 EXE 或 Interop DLL 失败？
（编辑）——我现在已经用五种不同的显示语言对此进行了测试；只有土耳其语失败了。
I'm utterly stumped, so what I'm looking for is a body of speculation. Or maybe someone actually knows what's going on.
I have a program written in VB6 which has had every user interface element font set to "MS Sans Serif, 7 point", in an effort to create an English/Turkish localization. The localized strings are compiled into the VB6 EXE, and there is custom code to do the hot-switching between languages.
The program reaches through COM to a .NET DLL assembly which carries a "tr" satellite assembly with it, so that is also in the mix.
With a clean test system set with the display language (NOT the non-unicode setting, the other, more general one) to "English" the software runs without problems.
When it is set to Turkish, the .NET Interop system returns "Run-time error '-2147024894 (80070002)' -- Automation error -- The system cannot find the file specified." as soon as (it appears) the .NET DLL is called. (EDIT: This may not be the .NET DLL. I've opened an incident with Microsoft for more information from a deep trace.)
Because this is a clean-system test, there were no diagnostic tools installed, but a trace with Sysinternals ProcMon failed to show me something I could recognize.
The question becomes: Is that the right tool to go tracing my obscure little "file not found" error? Are there better tools? What should I be looking for?
But most fundamentally, does anyone know what changes when the display language changes, that would cause either a VB6 EXE or an Interop DLL to fail?
(EDIT) -- I have now tested this with five different display languages; only Turkish is failing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我打赌你里面有一个我（i）！
我不知道你是如何加载 DLL 的，或者你是否只是将 UI 线程或工作线程的区域性更改为土耳其语，所以我可能有点偏离，但是...
仔细检查任何文件加载，任何文件加载如果它们中有 i、I，并且您正在使用大小写操作（降低、提高），那么土耳其语就会出错。
我们的 .net 应用程序也遇到了类似的问题，修复和使用特定文化来处理某些事情是很痛苦的，但你不能相信上或下以及土耳其语言！
祝你好运。
I bet you have an I (i) in there!
I don't know how you are loading your DLLs, or if you've changed just the UI Thread or the worker threads' culture to Turkish, so I might be off a little, BUT...
Double check any file loads, any paths, and strings of importance etc. If they have an i, I in them, and you are using case operations (to lower, to upper) it will all go wrong with Turkish language.
We had a similar issue with our .net app and it's a pain to fix and go round using a specific culture for some things, but you can't trust to upper or to lower and the turkish language!
good luck.
我无法解释这个错误的根源。相反，从安装程序中删除“AMUS”指令后，安装后不再出现该错误。根据微软在我做了一些测试后对问题的总结，无法再重现它：
所以...我将将此问题标记为对此答案的回答，并向该问题添加 Windows Installer 密钥。调用 Windows Installer 时请避开“AMUS”...
I cannot account for the source of this error. Instead, after removing an "AMUS" directive from the installer, the error no longer occurs after installation. According to Microsoft's summary of the problem after I did some testing and couldn't reproduce it any longer:
So... I'm gonna mark this one as answered with this answer, and add a Windows Installer key to the question. Steer clear of "AMUS" when calling Windows Installer...