VB6 Project File Structure, Syntax, Meaning, and Relevance.
Like many people probably still active in this forum, I just inherited a cluster of a VB6 project. My initial task is to get the project working on Windows 10 machines, but I am a bit rusty with VB6, and .NET programming in general (spent the last 5 years working with AWS cloud APIs and scripting languages).
I will apologize upfront if this post starts to get a little long winded, but context here is key.
What I am struggling with right now is all the 3rd party components that this project is using, again, I am guessing another common issue.
After a lot of finagling I was able to get the project to load without error on a Windows 10 development machine, and compile without error as well.
I had to track down several of the install files for these components/references, and some dlls and tlbs I had to register manually, but in the end I got the project to run.
My question here is about how this whole process works when installing and running the program on a Windows 10 client test machine.
My concern is with how much "finagling" I had to to do to get the project to run on my Windows 10 development machine.
More specifically, and detailed in the attached screenshot of one of the VB6 project files, I am worried about the DLL\TLB\OLB files and the GUIDs associated with them, and the location of the file as is referenced in the project.
Does the GUID referenced in the VB6 project file need to match the GUID on the client machine where program is installed, and if so how does that get enforced?
Does the location of the file referenced in the VB6 project file need to match the location of the file on the client machine where program is installed, and if so how does that get enforced?
Ideally I would like all the required DLLs, TLBs, OLBs, to be located under "SysWoW64" on the client machine, is this possible? If so how?
Link to screenshot below, thank you for taking the time to read!
VB6 Project File Structure, Syntax, Meaning, and Relevance.
Reply With Quote
