C＃/ COM互操作只在调试工作 [英] C#/COM interop working only in debugger
问题描述
我有从C＃应用程序的进程内COM服务器组件COM互操作的问题。
I have a problem with COM interop from a C# application to an inproc COM server component.
我已经减少了问题的一个简单的C＃测试程序。它实例化服务器组件的互操作类，设置一个字符串的值的属性上的实例，然后设置另一个字符串属性。我没有做什么不寻常与编组。刚开始使用的时候我加入了COM组件的引用产生的互操作类。是这样的：
I have reduced the problem to a simple c# test program. It instantiates the server component's interop class, sets the value of a string a property on the instance, and then sets another string property. I'm not doing anything unusual with marshalling. Just using the interop class generated when I added a reference to the COM component. Something like:
using MyLib; // Interop assy
// ...
MyComp comp = new MyComp();
comp.Prop1 = "abc";
comp.Prop2 = "xyz";
结果：
Outcomes:
-
如果我跑VS外的测试程序，然后，当第二个属性设置，我一直得到一个收到COMException与
0x80010105的HRESULT（RPC_E_SERVERFAULT）。
If I run the test program outside VS then, when the second property is set, I consistently get a COMException with an HRESULT of
0x80010105(RPC_E_SERVERFAULT).
如果我运行Visual Studio 2005的内部测试程序则始终正常工作。
If I run the test program inside Visual Studio 2005 then it consistently works correctly.
我在托管C写的等价代码++（没有ATL，只是普通的接口指针），这正常工作在国内外享有很高的。VS
I wrote equivalent code in unmanaged C++ (no atl, just plain interface pointers) and this works correctly both in and out of VS.
我的提问：什么是关于它可能占我什么调试器中运行时，会出现互操作环境的不同看见了什么？我假设 E_RPC_SERVERFAULT 正在由互操作编组产生的，但为什么只有在调试器？对于如何处理这继续有什么建议？
My question: what is different about the environment in which interop occurs when running inside the debugger that might account for what I'm seeing? I assume that the E_RPC_SERVERFAULT is being generated by the interop marshaller, but why only in the debugger? Any suggestions for how to proceed with this?
[我没有说太多关于COM组件，因为我的问题是关于不同的行为，我看到进出的调试程序。 COM组件是行之有效的，并已在生产中使用超过7年（每天成千上万的调用在服务器环境），所以我在这相当有信心。它是一种32位的DLL。我有来源，但目前并没有为它一个合适的编译环境。即使我这样做，我不知道如何调试到它从托管代码。这可能吗？]
[I haven't said much about the com component because my question is about the different behaviour I'm seeing in and out of the debugger. The com component is well tested and has been in production use for over 7 years (thousands of invocations per day in a server environment) so I'm quite confident in it. Its a 32 bit dll. I have the source, but don't currently have a suitable build environment for it. Even if I did, I'm not sure how to debug into it from managed code. Is this possible?]
更新
没有解决办法，但一些意见：
No solution yet, but some more observations:
- 我试图运行的应用程序作为管理员，并与UAC关闭。同样的结果。
- 我试图连接到过程发生前的错误，但我看到了在被抛出结构化异常输出窗口任何指示。
- 我想明确地设置测试应用程序的主线程STA，然后MTA单元模型，但是这并没有区别。 COM组件是单元线程。
- 我试图运行的托管测试应用（视觉工作室以外）一个Win2003的机器和不同的Win7专业版的机器上。它工作正常的两个。
- I tried running the application as administrator, and also with UAC turned off. Same result.
- I tried attaching to the process before the error occurs but I saw no indication in the output window of a structured exception being thrown.
- I tried explicitly setting the apartment model for the test app's main thread to STA and then MTA, but this made no difference. The COM component is apartment threaded.
- I tried running the managed test application (outside visual studio) on a Win2003 machine and a different Win7 pro machine. It worked correctly on both.
最后一个项目点，与我的机器的问题，但我不知道是什么。
The last item points to an issue with my machine, but I'm not sure what.
[环境是框架2.0的Win7专业版32位与Visual Studio 2005专业版上运行。]
[The environment is Framework 2.0 running on Win7 Pro 32 bit with Visual Studio 2005 Pro.]
推荐答案
有没有可能是你正在运行的值为anycpu构建，以及由于某种原因的Visual Studio加载程序集为32位，但是当你运行VS外的程序，它会作为64位，因而无法加载32位位COM DLL？
Is it possible that you are running an AnyCPU build, and for some reason Visual Studio loads the assembly as 32bit, but when you run the program outside VS, it runs as x64 and thus cannot load a 32-bit COM dll?
这篇关于C＃/ COM互操作只在调试工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
