6
votes

In VBP files, there are "References" and "Objects" as follows:

Reference=*\G{D63E0CE2-A0A2-11D0-9C02-00C04FC99C8E}#2.0#0#..\..\..\WINDOWS\system32\msxml.dll#Microsoft XML, version 2.0
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll
  1. What are the differences between these two?
  2. Why are some dlls referenced via Reference instead of Object or vice versa?
  3. Where is VB getting the filepath for Object references? The paths aren't specified for them in the VBP, nor does the GUID come up when I search my registry! However, when I load the project, VB tries looking for the dll/ocx/etc. at some absolute path (e.g. C:\path\to\dll\ieframe.dll). Where is it getting this path if it isn't in the registry or VBP?!
1

1 Answers

6
votes

Objects are for ActiveX controls which are usually compiled to .ocx files. References are for type libraries usually compiled to .dll files or .tlb files. Notice that .ocx files contain typelib too so this is very inconsistent and pretty much a legacy division.

Paths and filenames are optional, typelib IDs are canonical way to resolve dependency. Only if these are not found in registry there is a auto-resolve strategy searching for files in current folder for .ocxes only. This most annoying behavior happens at run-time too when the applications starts to auto-registering .ocxes in current folder if typelibs are not found and often fails on modern OSes for lack of permissions to write in HKLM.

There are Object lines in .frm/.ctl source files too. These get appended to current project if adding existing form/usercontrol.

If an .ocx typelib is added as Reference line the IDE usually fails to load the project and a manual edit is needed.