We've got a native library which we use to perform security related tasks for us. We've written an interop library so that we can use it from .NET.
We've got two test applications, the first application is written in C++ (unmanaged) and the second is written in C#. They generate the exact same sequence of calls to the native library, but produce different results.
I'm lost and can't find any apparent mistake in the .NET import definitions. I've already dumbed it down so that I only work with a very simple interface. I'm looking for ideas why calling a native library from a .NET environment might influence the result.
EDIT: I do not have in depth knowledge of the library, so I can't provide much on what is done in the native code. I know it does maintain a (heatbeat) thread. Another part of the library, which is used to identify whether the application is running on a VM, also exhibits the same behavior. This isn't necessarily related.
I wrote another test application in C++/CLI, since it is a little easier to consume the native library than from the C# and it is also giving the same result as the C#.
Wild guess: You marshal a function taking bool to a function taking bool. This gives different results when calling from native code and managed code because bool must not be marshalled to bool
One possibility would be if the native library makes use of native thread local storage. There isn't (necessarily) a one-one mapping between managed threads and native threads.
To eliminate this possibility, you could try wrapping the entire sequence of calls inside calls to BeginThreadAffinity/EndThreadAffinity (that is to say, a single pair of these calls across all calls into the library, not a pair around each individual call into the library)
Key words:
We've written an interop library so that we can use it (native library) from .NET.
This is the source of your errors not the native library. A specific native call (specific function call w/ specific parameters) will return same results no matter how it is called. The issue becomes that your wrapper can introduce subtle bugs where you "think" you are making the same call but the interop version is making a slightly different call (thus different results).
I would start with some very fine unit testing of your interop library at the lowest level. Native function foo(int x, int y). Call it natively, call it via library. Result should be the same. Continue until you find a function call where they are not. If there is a difference than the issue is with your marshalling & interop not the native library. If you find an individual call which returns difference results and you can't find the source of the error in interop then post individual call as a question on SO.
It could be a problem with marshalling / interop as others have suggested.
But it could also be that the native library is making assumptions about its environment that are not expressed only in the call signatures.
There are many ways such assumptions could be made. As a random example, a method in an MFC library that does not call the AFX_MANAGE_STATE macro may be making assumptions that are invalid when being called from .NET code.
来源：https://stackoverflow.com/questions/4304314/why-would-native-code-called-from-net-give-different-result-from-calling-it-fro