C# and DLL's
-
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
-
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
Ed Hopkins wrote: 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. Does the first function call always work? Have you tried calling different functions the first time to see if there is a problem? If your dll that you are writing in C++ is based on COM I would hightly recommend you read through information on Runtime Callable Wrappers[^] on MSDN. - Nick Parker
My Blog | My Articles -
Ed Hopkins wrote: 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. Does the first function call always work? Have you tried calling different functions the first time to see if there is a problem? If your dll that you are writing in C++ is based on COM I would hightly recommend you read through information on Runtime Callable Wrappers[^] on MSDN. - Nick Parker
My Blog | My ArticlesIt'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
-
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
Hmm, seems to me I've heard MFC doesn't play nice with other frameworks. And .NET is a framework. I've run into some strangeness with MFC. I remember I was experimenting with forms in DLLs and had one done in Delphi that I launched from a VC++ 6.0 MFC app using a worker thread. No matter what I did when I closed the DLL form, I got an exception. However if I displayed a messagebox in the VC++ app after closing the form, I never got an error. I chalked it up to Delphi having a VCL and MFC not being at the root of all the GUI stuff, but who knows? Of course the Delphi DLL form worked fine with every other app I used to launch it, such as Delphi and VB 6.0. Go figure. :)
-
Hmm, seems to me I've heard MFC doesn't play nice with other frameworks. And .NET is a framework. I've run into some strangeness with MFC. I remember I was experimenting with forms in DLLs and had one done in Delphi that I launched from a VC++ 6.0 MFC app using a worker thread. No matter what I did when I closed the DLL form, I got an exception. However if I displayed a messagebox in the VC++ app after closing the form, I never got an error. I chalked it up to Delphi having a VCL and MFC not being at the root of all the GUI stuff, but who knows? Of course the Delphi DLL form worked fine with every other app I used to launch it, such as Delphi and VB 6.0. Go figure. :)
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
-
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
Did you try searching knowlegebase for a bug report? You can't be the only one seeing DLL load lag if that's what's happening.