I have done extensive testing with this and have isolated the problem to this. I’m trying to keep this to the point but please ask if there’s any other information you feel I’m leaving out.
-a.exe is our vb6 app that references x.dll
-x.dll is an in house vb6 dll that references y.dll
-y.dll is an in house .net interop dll
-Everything works fine on the development machines.
-I have more than triple checked our .net setup project to ensure files are being pulled from the correct places.
When installed, a call from x.dll to y.dll fails. Ultimately how I am able to fix this is by copying x.dll from the development machine over the x.dll file that was installed by the setup project on the target machine. These two should be identical.
Anyone have any clues whatsoever what this could be? It’s pretty much the strangest dll problem I think I’ve ever had 🙁
Though I fixed the problem, I still don’t completely understand why there was a problem but here’s what I found…
Vb6 always wants to change the dll being referenced to the one most recently registered. We used to register dlls to an application directory located in C:\ and not within the source code folders, and we referenced them from there, and grabbed them from that directory for the install package.
When we switched to subversion we moved the dlls into a dependency folder within the branch. However, the dlls continued getting copied and registered to the application directory as well where the build would grab them from. I had to update the build to grab the dlls from the new branch location and stop them from being copied to the old location.
That seems to have fixed the problem, but I don’t fully know why because a comparison of the dlls in both locations showed they were identical.