3
votes

I'm maintaining a VB6 application with many COM components (DLLs and OCXs). In order to streamline development and deployment I'd like to use reg-free com. The problem with development is that the application runs within the VB6.EXE instance. How can I trick VB6 to use my (unregistered) components? It is very important for me to not have to go through registering/unregistering components when switching between branches. Generating a .manifest file for VB6 is not out of the question but is there some other, more optimal way, to specify a .manifest file when launching VB6.EXE?

Note: The Activation Context API doesn't seem to help, even if used from within the development environment.

Solutions I've thought:

  • A utility application that activates a context from a manifest and launches VB6 as a child process (doesn't work; processes don't inherit activation context)
  • Injecting context activation into the VB6 process at startup (too complicated; must hack the executable to do this)
  • Hosting VB6 in my own process after activating the right context (can't even find out if this is possible)
  • Using a VB6 Add-In or other utility that runs within VB6 to activate a context (tried that but it doesn't seem to work)

Update Jan. 16

As suggested by wqw, I did some testing with a VB.exe.manifest. The VB6.exe.manifest worked, with some caveats:

  • The SxS dll specified in the manifest would not appear in the references window on projects that didn't actually reference the component
  • On projects that did reference the component it would be shown to reside in the directory according to the following order:

    1. The pathname recorded in the project file (if the file was still present)
    2. A pathname as if it resided in the same folder as the project (vbp)

    If the file was not in any of these folders, the project would not compile (just running the code causes an internal compile in VB6) with the message "Can't find project or library".

Obviously, VB6 actualy scans the registry to find COM components and verifies, during compilation, that they exist where they say they exist. I'm not sure what that might mean if I actually want to use VB6.exe.manifest to redirect COM component instantiation. Perhaps having dummy component files at some predefined location might trick VB6 into believing that everything is as it should be, although an entirely different set of components got loaded for use.

Further update:

I did a test on that last assumption and it proved to be false. The component has to actually be there in order for the project to compile. It must even properly load (no dummy, zero-length files accepted!). Now I'm not even sure if the manifest works. That's a more time-consuming test (requires a component with two versions that produce different results, one with the project, and one for the manifest).

1
Did you try a manual VB6.exe.manifest for a single reg-free DLL/OCX? I don't think it will work as expected.wqw
Actually... no. But people report that they've done it successfully. I'll try it and get back to you on that.Doc
I'm trying to get VB6 to run with a manifest on order to debug a regfreecom dll but it's throwing an error when run - what were the contents of your vb6.exe.manifest that worked?Carl Onager
@doc I got mine working. it would be good if you added an answer detailing how you got yours workingCarl Onager
Most of your problem is that you are trying to use a packaging and deployment technology as a development technology.Bob77

1 Answers

1
votes

Our approach to this problem was to write a build assist program that registered and unregistered components, run the VB6 compiler, and would even rewrite project files with updated GUIDs when interfaces changed. You would hand it a VBG project group and it would do the rest.

I suppose we could also have added a mode that unregistered components when you switched branches.

Are you following the practice of using "compatibility" binaries? You shouldn't use the binary at your build location for compatibility references - you should commit a separate copy to version control and configure your project to consider that the "compatible" version - only change this file when you break interfaces.