Managing DLL calls from C#

Thanks Alan,

that's what I don't understand too. In C#, it was also much harder to get the errors in a console application, compared to a WinForms app, where it was showing errors all the time.

Petr

Whilst I can understand why not allowing for the value of the dwReason parameter would cause the variables to be re-initialized each time the system called DllMain, I can't really see why the problem would be any worse for a managed consumer as opposed to an unmanaged consumer of the dll :-/

Anyway, no matter, I'm pleased you've solved it :)

You've allowed for all possible dwReason values so there shouldn't be anything else to worry about.

So, we have probably found a solution. Originally, our DllMain function in the DLL looked like this:

BOOL APIENTRY DllMain( HANDLE hModule, DWORD dwReason, LPVOID lpReserved) {
   // Create devices :
   Adapter = new TPktAdapter;
   Bat1 = new TBat1;
   Bat1->Adapter = Adapter;
   return 1;
}

We thought the DllMain function will be called only once during DLL load, so we initialized all our modules here without any care about the dwReason parameter.

As it turned out, the DllMain is called more often for several reasons like DLL_PROCESS_ATTACH, DLL_PROCESS_DETACH, DLL_THREAD_ATTACH etc. That's why our modules were initialized every time the DllMain was called, which damaged our data.

Now the DllMain looks like this and everything seems to be working:

BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved) {
   if (dwReason == DLL_PROCESS_ATTACH) {
      // Create devices :
      Adapter = new TPktAdapter;
      Bat1 = new TBat1;
      Bat1->Adapter = Adapter;
   } else if (dwReason == DLL_PROCESS_DETACH) {
      delete Logger;
      delete Adapter;
      delete Bat1;
   } else if (dwReason == DLL_THREAD_ATTACH) {
      // Don't care
   } else if (dwReason == DLL_THREAD_DETACH) {
      // Don't care
   } else {
      // Unknown reason
   }
   return 1;
}

Are there any other thing we should take into consideration?

Petr

All I can think of  is that the cumulative overhead of repeatedly calling the dll functions via the P/Invoke mechanism is causing a synchronization problem in communications with the USB port.

Would it be feasible for you to try calling the dll from some other .NET language (such as C++/CLI or VB.Net) to see whether you experience the same problem as when calling it from C#?

I have just tried to run the same DLL call sequences from C++ and from C# and while the C++ version works perfectly, the C# stops working after some time. Both C++ and C# call the same version of DLL.

What can be the problem if I work with the DLL exactly the same way both in C++ and C#? Does it mean that the DLL is somehow dependent on the C#?

Petr

Thanks Alan,

nice to hear that the DLL will not be released until my app closes, so I can focus on the DLL itself. I have made some tests so far and it seems that it works perfectly when called from C++, I have problems only when calling from C#. We are going to test it more.

Petr

The dll will be loaded (if it hasn't already been loaded by another running process) when the first call is made via P/Invoke to the unmanaged function and, AFAIK, will remain loaded until (no sooner than) the application ends.

The only thing you could do to unload it before then would be to P/Invoke the API function FreeLibrary but it's not really a good idea to mess with the internal workings of the CLR.

So, if you're making repeated calls to GetDeviceVersion() then I think you can discount the possibility of any problems being caused by having to reload the library.There is a slight performance hit with any P/Invoke call but it's rarely noticeable.

As no parameters are being passed to the function, I can only think that the problem must lie with the dll itself. Does it always work faultlessly from C itself?