2

Yes, I know vb6 ancient and all that. It's still an interesting question. and the issue might not even be with vb6....

Background: We have a server running a vb6 application for our users who access this via Citrix. This installed application accesses its DLLs (also written in vb6) from a "shared folders" location.

What I want to do is have the previous version of this same app on the same server, accessing it's own set of (previous versions) DLLs. I am half way successful. the renamed app in another directory runs. But it crashes immediately upon using any feature that draws from the DLL's code.

Apparently the registered DLLs of the current version are being called upon. I dont want that. I want the DLLs found in the same directory as the renamed older app to be called upon.

Can that happen in a windows server? is this an installer's settings issue? Have you ever had this situation before? were you successful?

thanks in advance. Harry

Post Script: The bosses decided that experimenting with the DLLs and system settings was a waste of my time and not worth the risk. So they're throwing money at it and another server will come online for the sole reason of providing the previous version to the citrix users who want it. Thank you to all of you who pitched in with great tips and leads to other posts. (yeah I'm sort of disappointed too. Kind of wanted to know what the solution was to this.....)

Harry A
  • 105
  • 1
  • 10
  • By registered, you mean what? ocx files? – Anders Oct 20 '21 at 23:18
  • 1
    @Anders or it could be files with a DLL extension. If they were created by VB6 or are COM DLLs from somewhere else, that would be typical. – StayOnTarget Oct 21 '21 at 11:22
  • 2
    Does this answer your question? [How can you force VB6 to use the DLLs and OCXs from the app directory?](https://stackoverflow.com/questions/345111/how-can-you-force-vb6-to-use-the-dlls-and-ocxs-from-the-app-directory) – StayOnTarget Oct 21 '21 at 11:27
  • 1
    You can do this with a manifest file for the DLLs but custom licensed controls inside OCXs might have troubles. For stock licensed controls (ComCtrl, etc.) you can keep these regsvr32 registered in registry outside of the redirecting manifest. We have all out VB6 apps regfree on Terminal Servers and deploy different builds with xcopy. – wqw Oct 21 '21 at 13:27

1 Answers1

1

The OS should be looking for the dll’s in the following places and order

  1. The directories listed in the App Path registry key (HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths) if any
  2. The directory where the executable module for the current process is located
  3. The current directory
  4. The Windows system directory
  5. The Windows directory
  6. The directories listed in the PATH environment variable

Given that you are using a shared folder for your dll’s, I would suppose that the app is setting the current directory to your shared folder OR is using the PATH environmental variable to specify where to look. I don’t think it is using the app path registry key path because that is version specific and you said you are using a different version.

I would suggest your try setting the path via HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

jmoreno
  • 12,752
  • 4
  • 60
  • 91
  • 3
    If they are COM DLLs than I don't believe this is correct. The app will look for registered classes and the DLLs registered to implement them. VB6 DLLs were COM-based, normally. – StayOnTarget Oct 21 '21 at 11:23
  • 1
    thank you @jmoreno for your help. I'll investigate these avenues and see if any apply to me. I have to be sure to not upset the current version install, so I hesitate to play with registry settings. Though I can take a look and see if the installer has set something up in HKLM\software. thank you again. – Harry A Oct 22 '21 at 00:39
  • 1
    and @StayOnTarget thanks for the posting tip. I'll read up on that and see if there's anything there I can safely try (without making a few hundred users angry) – Harry A Oct 22 '21 at 00:40
  • 4
    @StayOnTarget is correct, so without recompiling the DLLs with a different class name and registering them, the OS will always load the registered DLLs, as these are the ones referenced and compile against in the VB application. – Hel O'Ween Oct 22 '21 at 07:06
  • I tried added a bob.exe.local file to the app directory. That was supposedly going to trigger Dynamic-Link Library Redirection. And I added in the new variable DevOverrideEnable and set it to 1. so far no success. – Harry A Oct 22 '21 at 13:30
  • @HarryA that's a good detail to add to the question itself. Seems less relevant as a comment on this answer (which doesn't mention it) – StayOnTarget Oct 22 '21 at 17:56