Question

I’m responsible for maintaining legacy VB6 code, and have encountered an annoying problem with regard to the locking of a project’s COM DLL. (We’ll call it MyProject and MyProject.dll)

When I load MyProject into the VB6 IDE, I am able to compile the resulting binary-compatible DLL MyProject.dll. I can then run my (Classic ASP) web application that hooks into the DLL (or anything else for that matter).

So, when I try to recompile the COM DLL, I get a ‘permission denied’ error. I then find myself having to carry out the following steps in order for the DLL to be unlocked:

1. Check I have no dependant projects open in other VB6 IDEs
2. Recycle IIS
3. Check the file isn’t read only (sometimes it will be if I have checked it in to source control)
4. Close the project and reopen it.

Often it is the last step that fixes the issue, and allows me to recompile, which means that the VB6 IDE is actually locking the DLL of the loaded project!

My colleague explained to me that it was to do with the way a VB6 project works with binary compatibility upon the DLL, but was unable to suggest a resolution.

My searches elsewhere have yielded very little in the way of answers. Search queries that are related to this tend to return a lot of unrelated answers (maybe I’m asking the wrong thing of search engines).

The closest thing I could find on Stackoverflow was this question from a couple of years ago, but it doesn’t really fit the bill.

Does anyone have any other suggestions that might ameliorate this?

Answer 1

Keep a copy of MyProject.dll named MyProject.cmp and point binary compatible setting to your .cmp file. This way you won’t need reopening project file (step 4).

During check-in you can mark keep checked-out to skip step 3 too.