Wrapped COM call works during Test, otherwise fails
-
I have an unusual situation. A call from C# to C++ using static extern references to an un-mananged dll works perfectly during execution of TestClass/TestMethod unit testing within Visual Studio 2008. However, during debug (not during Testing) and normal execution, we receive an exception from the underlying COM object for which the C++ dll is a wrapper. And, right on queue, the third party COM object gives no detail why it failed. I cannot much paste code because of proprietary reasons, however, here is the extern from C# which works fine under the context of unit testing (TestClass/TestMethod) in VS 2008.
[DllImport("BTDataAccess.dll")]
static extern uint BTReadBu( [In, MarshalAs(UnmanagedType.BStr)] string filePath);Few notes, we do have the c++/unmanaged copied to both the C# test project and console app. Additionally, the list of c# project refernces between test and console projects have been reviewed. Any ideas regardless of how far out they are would be appreciated.
-
I have an unusual situation. A call from C# to C++ using static extern references to an un-mananged dll works perfectly during execution of TestClass/TestMethod unit testing within Visual Studio 2008. However, during debug (not during Testing) and normal execution, we receive an exception from the underlying COM object for which the C++ dll is a wrapper. And, right on queue, the third party COM object gives no detail why it failed. I cannot much paste code because of proprietary reasons, however, here is the extern from C# which works fine under the context of unit testing (TestClass/TestMethod) in VS 2008.
[DllImport("BTDataAccess.dll")]
static extern uint BTReadBu( [In, MarshalAs(UnmanagedType.BStr)] string filePath);Few notes, we do have the c++/unmanaged copied to both the C# test project and console app. Additionally, the list of c# project refernces between test and console projects have been reviewed. Any ideas regardless of how far out they are would be appreciated.
Have you tried changing calling convention: [DllImport("BTDataAccess.dll", CallingConvention=CallingConvention.SomeCallingConvention)] I already had problems when debugging/running by different calling conventions, as some exceptions are not thrown immediatelly on release code (but are still wrong). Maybe that's the case... maybe. Try the charset also. I am only guessing, as I really don't know what is causing the problem.
-
Have you tried changing calling convention: [DllImport("BTDataAccess.dll", CallingConvention=CallingConvention.SomeCallingConvention)] I already had problems when debugging/running by different calling conventions, as some exceptions are not thrown immediatelly on release code (but are still wrong). Maybe that's the case... maybe. Try the charset also. I am only guessing, as I really don't know what is causing the problem.
Thanks for the suggestion, however, none of the five CallingConvention enum values fixed the problem. What do you mean by charset? On another note, we are running this as a single-threaded operation. There is a call to the c++ unmanaged dll made prior to the one in question. However, it is tasks with simply instantiating a COM object. This first call and the second one which fails is performed on the same thread. Multi-threaded operations on COM brings a lot of issues, but this isn't the case here. I realize each unit test in VS is on its own thread, however, we rigged it that calls to the same COM object are not performed from different threads.
-
Thanks for the suggestion, however, none of the five CallingConvention enum values fixed the problem. What do you mean by charset? On another note, we are running this as a single-threaded operation. There is a call to the c++ unmanaged dll made prior to the one in question. However, it is tasks with simply instantiating a COM object. This first call and the second one which fails is performed on the same thread. Multi-threaded operations on COM brings a lot of issues, but this isn't the case here. I realize each unit test in VS is on its own thread, however, we rigged it that calls to the same COM object are not performed from different threads.
You use string. There is the CallingConvention and the CharSet properties. Also, the calling convention can be wrong in the method that was called just before. So, if you instantiate a COM object and after call a method, is possible that the instantiation is using an invalid calling convention. But, I am unsure... why you can't simple import your Com object by Visual Studio Add Referece? It creates the the available components with the right calling convention.
-
You use string. There is the CallingConvention and the CharSet properties. Also, the calling convention can be wrong in the method that was called just before. So, if you instantiate a COM object and after call a method, is possible that the instantiation is using an invalid calling convention. But, I am unsure... why you can't simple import your Com object by Visual Studio Add Referece? It creates the the available components with the right calling convention.
Ok, the plot thickens. A fellow developer wrote a bare-bones c# app that calls the c++ wrapper dll and it works from his computer. However, it fails from mine. I tried each type of CharSet without success. Also, I tried it with callingconvention = CallingConvention.StdCall. Btw, we used to use the automatically interop dll for calling the COM directly, however, it was very unstable. The funny thing is that stability is perfect with the approach using a hand-written c++ wrapper if called from c# under the context of visual studio unit testing.