调用 C++ 时出现 System.AccessViolationException；来自 C#
我不知道为什么，但今天 myOpenID 似乎不起作用。无论如何...我有这个问题：我有一个非托管 C++ 库 (DLL)，我必须将其嵌入到现有的 C# 项目中。现在...我已经在托管 C++ 中创建了一个迷你包装器 (DLL)，它调用该库，以便我可以从 C# 代码加载它，并且当我从命令行 C# 项目中尝试它时，它完美地工作了，对吧结果，正确的行为等等。
现在，当我将它加载到实际项目中时，它开始给我带来来自迷你包装 DLL 的奇怪 System.AccessViolationException 异常。我没有 C# 经验，也没有 Windows 下的托管/非托管 C++ 开发经验，我只是不明白为什么这应该在 C# 项目中工作，而不是在另一个项目中工作。
更多信息：原始库使用OGRE3D渲染引擎进行计算，而我必须使用该库的项目在幕后使用OGRE，这会导致问题吗？
有什么建议吗？
I don't know why but today myOpenID doesn't seem to work. Anyway ... I have this problem: I have a unmanaged C++ library (DLL) which I have to embed in an existing C# project. Now ... I have created a mini-wrapper (DLL) in managed C++ which calls the library so that I can load it from the C# code and, when I try it from a command-line C# project, it perfectly works, right results, right behavior ecc.
Now, when I load it in the real project, it starts giving me strange System.AccessViolationException coming from the mini-wrapper DLL. I am not experienced in C#, nor in general manged/unmanaged C++ development under Windows, and I just can't understand why should this work from a C# project, and not work from another.
More information: the original library uses OGRE3D rendering engine to do calculations, and the project in which I have to use this library uses OGRE under the hood, could this cause problems?
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
先生，这里有一些想法供您尝试...
很难确切地知道发生了什么，但我要做的第一件事就是从混合物中删除这个托管 c++ dll。这可能会让事情变得混乱。在这里的某个地方，感觉数据在托管和非托管世界之间没有正确编组。另外，仅仅因为它不会从控制台崩溃，并不一定意味着代码工作正常，它仍然可能会被破坏，只是不会触发访问冲突。我首先要考虑的是使用 p/invoke 直接调用您的非托管 dll，如果它损坏，您应该很快就会知道：
使用 P/Invoke 在 C# 中调用 Win32 DLL
可能是在混合中的某个位置，此指针被移动到了该指针使得的不同地址空间没有意义。这里有任何进程边界吗？
Here are some ideas for you to try sir...
It's hard to know whats going on exactly but the first thing I would try to do is remove this managed c++ dll from the mix. It might be confusing things. Somewhere here this feels like data is not being marshalled correctly between the managed and unmanaged world. Also, just because it doesn't crash from the console, doesn't necesarilly mean the code is working correctly, it could still be breaking, just not in a way thats triggering an access violation. The first thing I would look at is using p/invoke to call your unmanaged dll directly, if it breaks, you should know pretty quickly:
Calling Win32 DLLs in C# with P/Invoke
It could be that somewhere in the mix, this pointer is being moved to a different address space where that pointer makes no sense. Are there any process boundaries here?