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). :eek:

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! :thumb:

https://i.imgur.com/gW4E1L7.png

Quote:

---

Originally Posted by guht

My question here is about how this whole process works when installing and running the program on a Windows 10 client test machine.

---

This is a question about packaging and deployment, not programming. We have a forum for that here. ;)


One problem with a lot of 3rd Party components is that they do not come with a proper developer-installer package that includes the .DEP file that is used to guide packagers. Of course some do not rely on a .DEP file but expect Installer Merge Modules instead that embed the necessary rules.

Another issue is that over time a lot of things have become system components that should not be deployed. You must either deal with those manually when packaging or update the rules database (VB6DEP.INI, various .DEP files in the case of the PDW). A lot of 3rd Party packagers don't have such a database in any form and you are completely on your own. It is like driving a car with long sticks taped to the throttle and brakes, ropes tied to the front axle to steer, etc. instead of normal driver controls.

There are similar issues with the C/C++ runtimes.

The .DEP files or Merge Modules should define the target location for deployment of 3rd Party libraries. The only thing that should ever go into Sytem32 (SysWOW64) are Microsoft libraries. Dumping anything else there is an error, though a common one.

It is a rare case when a .TLB file needs to be deployed to target machines. These are basically predigested source code (not object code) and as such they are normally only used by development tools. Those .OLB files are just a form of .TLB file.


Packaging and deployment is a skill as complex as programming itself. There is no shortcut to doing it correctly. Experience counts, especially in the post-Win9x post-XP world.

I can only speak for the Microsoft installer, but if a newer version already exists on the install computer, it will not overwrite it, as most of them are backwards compatible. And most of the standard files already exist on current operating systems. When a file is required to be installed in the %WindowsSystem% directory, the operating system itself will detect if a file is 32 bit or 64 bit, and install it in the appropriate location. The only issue that I have run into is with databases on Windows 10. MDAC cannot be installed on Windows 10, but all the necessary components are already there. They just might have to be activated. Don't ask me how, because I have found Windows 10 to be a convoluted nightmare that I still haven't completely found my way around.

J.A. Coutts