3F / DllExport

.NET DllExport with .NET Core support (aka 3F/DllExport aka DllExport.bat)
MIT License
940 stars 131 forks source link

FreeLibrary doesn't seem to behave as I expected #118

Closed justinweinberg closed 4 years ago

justinweinberg commented 4 years ago

Hi.

First, thanks for the awesome library. DllExport potentially enables scenarios for us that we didn't think possible without a lot more effort or maybe COM.

What I think I am seeing in Delphi and C# no matter how I do it is that calling LoadLibrary, GetProcAddress, and then FreeLibrary for the simplest DLLExport example (no args, return int) isn't behaving quite like I thought it would.

I thought:

1) Static variables would clear. This does happen if two different Win32 threads call LoadLibrary. 2) I would be able to copy over the DLL after a call to FreeLibrary like I can for Delphi DLLs. But instead the C# DLL remains locked as if the references did not count back to zero (as if FreeLibrary didn't work).

Am I misunderstanding how this all works or is there an option I need to tick?

Much thanks for any insight you can offer.

3F commented 4 years ago

1) I'm not sure what are you trying, but looks like you need [ThreadStatic] attribute. 2) This is how domains works in CLR. And this is it, module cannot be unloaded from the address space of your calling process because the reference count will not be equal to zero due to active domain with its loaded types.

Please use MSDN, stackoverflow, and other for understanding common practice with net-domains, and multithreading at all.