Determining who has an open file handle on DLLs in the GAC

I recently needed to update a solution in my SharePoint farm however:

1. The update required administration and connection permissions to the User Profile Service Application (UPA)
2. Some assemblies in our solution was causing the the UPA to be inaccessible

So, my code is broken and needed update, my update is broken because it can't access UPA, my UPA is broken because of my code ... argh!

Then, I had this idea, figure out which DLLs were breaking the UPA and update those directly in the GAC, hoping that it will at least free up the UPA so the update. I figured my DLLs were reasonably compatible over the different versions. So this is what I did:

1. Grab my updated WSPs
2. Use 7-zip to open the WSPs and extract the DLLs I needed
3. Open up the GAC (C:\Windows\Assembly)
4. Copy the DLLs I need into the GAC
5. Verify, by version number, that my DLLs were indeed copied into the GAC (I have seen cases where the copy seems to work, but nothing actually happens)
6. iisreset
7. restart owstimer
8. Run my installer to update my code as normal.

This worked very well for me, but when a colleague tried it, he found that he was unable to get step 4 working. He kept getting access denied issues. It turns out that he had UAC turned on and some processes (not just iisadmin) had an open file handle on the very DLLs he needed to update. Getting around the UAC issue is just a matter of running things as administrator. To solve the file handle issue, we used Handle from Sysinternals. 

Now it was simply a matter of opening up a command prompt and doing something like this:

Handle.exe c:\Windows\assembly\gac_msil\<your DLL name>

Handle will also recurse into subdirectories for you! Now it's just a matter of stopping those processes and continuing on.