On Friday, 10 May 2019 at 19:10:05 UTC, Machine Code wrote:
Well, I've had similar issue. The error message says "access denied" which I believe refers to the tmp directory; i.e, the user that is running your executable has no permissions to delete that file.
Well, this has nothing to do with access rights, the user have full access to his own temp folder even in the most restrictive windows configuration.
According to winapi docs, FreeLibrary doesn't guarantee file close op, and that's why you cannot delete it. Internally, windows maps a memory handle directly into the dll file and that pointer remains active until the application exits.
Actually, I ran your example with several sequential calls to FreeLibrary, all returning success, even if it's clear that the internal reference count touched zero after the first call.
The lock of the file disappears effectively after the application has exited and the dll can be safely deleted afterwards.
If you want this dll deploying mechanism (which I consider a bad approach, contributing to the well known dll hell) check at startup if the dll already exists, delete it and redeploy if the existing one doesn't satisfy your version requirements.
To avoid dll hell, dlls must be deployed in the system dir, or at least in the application folder through a normal installation process. In our network environment governed by a restrictive GPO, your application will never run.
