com-interop

My problem is simple, I have an event declared in a VB6 library that passes out a boolean argument: Public Event WriteComplete(ByVal aCommsOk As Boolean, ByVal aBadPIN As Boolean) I have hooked my c# code up to this event many times but bizarrely my testing department and a couple of other ppl have noticed that although VB6 raises this event with aBadPIN set to false, the c# event handler receives it as true. It is not consistent so it's one of 'those' problems but I'm not finding anything on the internet to help much. I have found that if I define a new event that converts the bool to a byte

I'm trying to force an existing native C++ ATL in-proc COM server into a separate process. I hope DCOM can do this for me without changing the COM server. I started with a usual registry setup - I have a HKCR\CLSID{classId} entry and an InProcServer32 key there specifying the path to the .dll file. I generated an application id (GUID) and added it here and there. Specifically I added a string value "AppId" under HKCR\CLSID{classId} equal to the application id. I also added a HKCR\AppId{applicationId} key and a string value "DllSurrogate" equal to an empty string. I thought it would be enough

I have a C++ DLL that is creating an instance of a COM object that's implemented in .NET. Under many circumstances this works fine, but under certain circumstances, it hangs the application, and I see it stuck with the following call stack (this is just the part underneath the level of my DLL's code): ntdll.dll!_NtAlpcSendWaitReceivePort@32() rpcrt4.dll!LRPC_CASSOCIATION::AlpcSendWaitReceivePort(unsigned long,struct _PORT_MESSAGE *,struct _ALPC_MESSAGE_ATTRIBUTES *,struct _PORT_MESSAGE *,unsigned long *,struct _ALPC_MESSAGE_ATTRIBUTES *,union _LARGE_INTEGER *) rpcrt4.dll!LRPC_BASE_CCALL:

I am implementing a c# COM client against a C++ COM server. The COM client functions correctly when I mark the COM interface as "Dual" but it throws an InvalidCastException when I remove the "Dual" attribute. Therefore the easy fix for me is to mark it as Dual. But from reading online, it looks like it is not the recommended approach to use for COM servers. Can anyone explain to me the significance (in layman terms) to marking an interface as dual and why it would not be recommended? I only need it for testing purposes, and I'm using C# client (don't anticipate that I ever will use VB)

I'm currently working on a mixed native / managed application chain, which employs registration-free COM. The following image illustrates this: The C# wrapper DLL has been created using the tlbimp.exe utility. This allows each of the C# executables to access the native types and methods in the COM DLL. The COM DLL itself employs a server based RegFree COM manifest. Everything works fine, when the client based RegFree COM manifests are embedded in the C# executables. However, I would like to move and unify these manifest files into the C# DLL, which would ease maintenance and synchronization of