DLL锁定-Visual Studio 2010 C ++

Question

I'm currently logged onto a machine and my current problem involves a custom build step that has trouble copying a .dll to the Bin directory because Windows says it cannot access the file because it's currently being used by another process.

I'm able to reproduce this on several other projects. The sequence of events is that I build a release successfully, do some test, checkout another SHA when doing a git bisect, and attempt to build a release from that SHA without doing a git clean -xfd (intentionally, because I'm trying to cache as much reusable data as possible). The weird thing is that I tried to use Process Explorer (procexp) and tasklist /m <locked_dll.dll> to search for whatever is holding onto this dll, and am unable to find anything holding onto the dll. I'm on a non-admin account, and I'm not sure if that is causing Windows to hide certain processes from me. Rebooting the machine helps, but that's not an acceptable solution since I'm trying to automate things. I'm able to delete the .dll, and when I try to build the project in VS, it'll complain that it still can't access the dll when trying to copy it over to the Bin folder. Any ideas? I'm going to keep researching the issue, but as of right now, I'm sort of stumped.

EDIT: This seems to be a duplicate question ( Error: Cannot access file bin/Debug/... because it is being used by another process ), but I'll leave this open to see if anyone has found anything new related to the topic.

Answer 1

I've seen this problem in VS 2010 with a large .Net solution with multiple projects in it. Every case I've seen so far pertains to have one project with dependency DLLs that another project also uses, and that other project also uses the first project as a reference, and also uses the same dependency DLLs that happen to be a different version from the first project.

To describe it a different way:

Project A depends on v1 of DLL A

Project B depends on project A and v2 of DLL A

Both project A and B are in the same solution

The solution is to use the same version of DLL A. I usually run into this when upgrading to a new version of SQLite, and I forget to update the dependency in all of my projects.

Answer 2

After talking with a few coworkers, I found the solution to my problem. procexp and tasklist did not see which process was locking the dll because there was no process locking the dll on that particular machine.

I have a hardware configuration where machine A (a host PC) is connected to machine B (acts as a client that retrieves instructions from machine A) using a network switch. machine B runs the same binaries that link to the same dll's. Thus, obviously, running procexp or tasklist on machine A will not see anything locking the dll's because machine B is the culprit.