views:

43

answers:

1

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?

Many thanks.

+1  A: 

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.

wqw
Yeah, that would work. Good idea. However, wouldn't this mess up the project environment a little for someone who hasn't created the copy as you suggested?
James Wiseman
...and as for the checkout - I do normally, but sometimes I forget! It was really just to highlight the hassle I have to go through to get the DLL to compile! :-)
James Wiseman
+1 this is a good idea for several reasons and is recommended in the VB6 manual http://msdn.microsoft.com/en-us/library/aa733706(v=VS.60).aspx @James The binary compatible settings are in the VBP, so everyone will be using the same settings. I'm assuming you keep the VBP file in source control? I'd recommend also keeping the `MyProject.cmp` in source control
MarkJ
Interesting idea. Seems like it would solve the problem but may introduce another. How do you keep the .cmp file updated?
Corin
Thanks to all. This is what I went for. It actually solves another problem for me when I have to change the interface in a development version. Pointing at the .cmp file actually helps maintain the compatibility until i want to ship, then I update the .cmp file.
James Wiseman