在 Visual C 的调试模式下找不到 MSVCR90D.dll; 2008年
我在使用 Visual C++ 2008 时遇到问题。我已经安装了 opencv,并且创建了一个新程序,并且构建它时没有错误。 但是,它抱怨在调试时找不到 MSVCR90D.dll。 在发布模式下完全没有问题。
我的 Winsxs 文件夹之一中确实有 MSVCR90D.dll。 有谁知道解决这个问题的方法吗? 这是一个已知的错误?
杰拉德
I have a problem with Visual C++ 2008. I have installed opencv and I've created a new program and I build it with no errors. However, it complains about not finding MSVCR90D.dll when debugging. In release mode there is no problem at all.
I do have MSVCR90D.dll in one of Winsxs folders. Does anyone know a get-around to this problem? Is this a known bug?
Gerard
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(11)
我尝试了所有建议的解决方案,但没有任何运气。 我终于发现
"C:\WINDOWS\WinSxS\Manifests"
文件夹中缺少清单。在
C:\WINDOWS\WinSxS
中找到您的 dll 所在的文件夹。 检查C:\WINDOWS\WinSxS\Manifests
中是否存在与您的 dll 文件夹名称匹配的清单。 如果清单丢失,请从另一台计算机复制正确的清单并将其粘贴到清单文件夹中。 清单文件名是:I tried all the suggested solutions without any luck. I finally found that the manifest was missing from the
"C:\WINDOWS\WinSxS\Manifests"
folder.Find the folder in
C:\WINDOWS\WinSxS
where your dll is located. Check to see if there is a manifest inC:\WINDOWS\WinSxS\Manifests
that matches the folder name of your dll. If the manifest is missing, copy the correct manifest from another machine and paste it into the manifest folder. The manifest file names are:我遇到了类似的问题,但所描述的解决方案都不适合我。
最后,我执行了以下操作来解决我的问题:
第 1 步:
给出的建议
按照@user176861 Step-2 :
在VC++项目属性-> 配置属性-> 链接器-> 清单文件:
在“其他清单依赖项”中添加以下内容:
进行上述更改后,我能够进行调试。
I faced the similar problem but none of the described solutions worked for me.
Finally I did the following to fix my issue:
Step-1:
Follow the suggestion given by @user176861
Step-2:
In the VC++ Project Properties -> Configuration Properties -> Linker -> Manifest File:
In the "Additional manifest dependencies" add the following:
After making the above change, I was able to debug.
此
那里有一个提示:
还有另一个:
确认最后一项:
There are several potential solutions described in this forum post. See if any of those help.
One hint from there:
And another one:
Confirming the last one:
遇到同样的问题,我找到了一篇文章,引导我找到 VS9.0 安装中的调试 DLL。 对于默认安装,它们位于:
C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT
。共有三个 DLL 和一个清单文件。 您可以将这些文件添加到您的
System32
目录中,将该目录添加到您的PATH
环境变量中,或者在调试时将文件复制到与可执行文件相同的目录中。增量链接可加快构建速度(链接器仅重新链接已更改的库,而不是重新链接整个项目)。 否则它对构建输出没有影响。 对于大型项目,我不建议关闭增量链接。
Having the same problem I found a post that lead me to the debug DLLs in the VS9.0 install. For the default install they were in:
C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT
.There are three DLLs and a manifest file. You can add these to your
System32
directory, add the directory to yourPATH
environment variable or copy the files to same directory as your executable when debugging.Incremental linking speeds up your builds (the linker only re-links libs that have changed instead of re-linking the entire project). It otherwise has no effect on the build output. For a large project I would not recommend turning off incremental linking.
尽管另一个VC9.0项目做得很好,但也有同样的问题。 所以我比较了两个项目设置。
关键的区别在于“项目属性”-> '配置属性'-> '清单工具' -> '输入和输出'-> “嵌入清单”。 该选项必须设置为 YES。
Had the same problem although another VC9.0 project did well. So I compared both project settings.
The crucial difference was under 'Project Properties' -> 'Configuration Properties' -> 'Manifest Tool' -> 'Input and Output' -> 'Embed Manifest'. This option must be set to YES.
使用 Dependency Walker 解决 DLL 问题要容易得多。 它允许您分析您的应用程序,捕获启动时加载的 DLL 和稍后加载的 DLL。 它会吐出大量与加载 DLL 相关的消息,或者加载失败的消息。 它还理解 DLL 的 SxS 加载。
您可以将 EXE 作为参数传递给 Depends.EXE,它将分析该应用程序。 这可以与大多数 IDE 结合使用。 例如,在 Visual Studio 中,您可以设置“调试命令”。 默认情况下,这是您自己的 EXE。 将其更改为depends.EXE,并将命令参数设置为(至少)
/pb your.debug.exe
。Troublehooting DLL problems is a lot easier with Dependency Walker . It allows you to profile your application, catching both DLLs loaded at startup and DLLs loaded later. It will spit out a lot of messages related to the loading of DLLs, or the failure to load them. It also understands SxS loading of DLLs.
You can pass an EXE as a argument to Depends.EXE, and it will profile that app. This can be combined with most IDEs. For instance, in Visual Studio you can set the "Command for Debugging". By default, that's your own EXE. Change it to depends.EXE, and set the command arguments to (at least)
/pb your.debug.exe
.使用函数 File->New->Project From Existing Code 在 VC++ 2008 中重新编译项目。
它帮助了我自己,可能也会帮助你。 问候。
Recompile your project in VC++ 2008 using function File->New->Project From Existing Code.
It helped myself, probably it will help you. Regards.
我已经解决了同样的问题,如下所示:
当您这样做时,您的项目会嵌入依赖的 dll,因此它避免了依赖问题。
注意:我从事一个 dll 项目并遇到了这个问题。 完成上述步骤后,它适合我的情况。
I have solved same problem like below:
When you do that, your project embeds depended dlls and so it escaped dependency problems.
Note: I worked on a dll project and had that problem. After doing above steps it worked for my situation.
这是我静态链接的原因之一; 更大的 EXE,但我以前从未遇到过这样的依赖问题。 不过,它本身可能值得一个问题......
This is one of the reasons that I statically link; bigger EXEs but I have never had a dependency issue like this before. Probably worth a question in itself though...
我无法给出明确的解决方案,但这里有一些有用的链接:
以及当然,如果您点击链接,MSDN 上还有更多内容。
I can't give a definitive solution, but here are some helpful links:
And of course, there's a lot more on MSDN if you follow the links.
我遇到了问题:
无法加载文件或程序集“AudioInterface,Version=1.0.3548.29920,Culture=neutral,PublicKeyToken=null”或其依赖项之一。 由于应用程序配置不正确,该应用程序无法启动。 重新安装应用程序可能会解决此问题。 (HRESULT 异常:0x800736B1)
AudioInterface 是我的 C++ 项目的名称。
切换到“发布”配置,一切正常。
我跟踪它是因为我的 DLL 旁边缺少清单文件,我进一步跟踪它有一个程序集标识集。 (属性 > 清单工具 > 常规 > 程序集标识)
我删除了此设置,清单放在正确的位置,一切正常。
I had the problem:
Could not load file or assembly 'AudioInterface, Version=1.0.3548.29920, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)
AudioInterface was the name of my C++ project.
Switching to "Release" config, everything worked.
I tracked it to lack of the manifest file alongside my DLL, which I further tracked to having an Assembly Identity set. (Properties > Manifest Tool > General > Assembly Identity)
I removed this setting, and the manifest dropped in the right place, and everything worked.