Well if implemented correctly MFC is capable of being accessed by other types of compilers ... that in itself is not the issue. The issue is that the way that C# loads DLL's is a bit strange coming from C++ ... I suspect VB does it the same way, I've developed a hacky workaround but it would be nice to know from a real C# expert why this is happening. In fact, forget I even mentioned MFC if you do it with a Win32 (or a Delphi) DLL it will load the same way. I did a little Delphi work myself at one point. Ed

It's not quite that simple ... it works A-OK from the VC++ demo app. It's NOT written in COM just a standard Win32 MFC DLL written in VC++. The timing appears to be due to the finite # of milliseconds it takes for the DLL objects to get created. They are not ready yet, and a subsequent call returns an error since it is pointing to things that are not yet created. Quite strange. Ed

I am writing a DLL in VC++ that needs to be called by one of our customers who use C#. Unlike my VC++ test application, which statically links the DLL to the EXE and creates the object upon startup, the C# application appears to load the DLL at runtime at the first reference to a DLL call (using the import keyword). THe problem is that subsequent calls to other functions do not work. It seems that there needs to be some pause for the load to happen. Has anyone encountered a similar problem? Ed Hopkins