4

Is there any available documentation on the Keys/Values used in the VBP (Visual Basic Project) file? I'm trying to achieve a better understanding of how VBP handles references internally.

Example Line:

Reference=*\G{BF204980-5E29-4945-AEB5-DDB284C568D3}#1.0#0#..\Project1.dll#Project1
StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
silentfrost
  • 302
  • 2
  • 10

2 Answers2

7

The syntax of references is described in [MS-OVBA]:

LibidReference     = "*\" LibidReferenceKind LibidGuid 
                     "#" LibidMajorVersion "." LibidMinorVersion 
                     "#" LibidLcid 
                     "#" LibidPath 
                     "#" LibidRegName

<LibidReferenceKind>: 

%x47 (G) <LibidPath> specifies a Windows file path.

%x48 (H) <LibidPath> specifies a Macintosh path.    

<LibidGuid>: The GUID of the Automation type library.

<MajorVersion>: An unsigned integer that specifies the
major version of the Automation type library.

<LibidMinorVersion>: An unsigned integer that specifies the
minor version of the Automation type library.

<LibidLcid>: The LCID of the Automation type library.

<LibidPath>: The path to the Automation type library.

<LibidRegName>: The Automation type library’s display name
Igor Skochinsky
  • 24,629
  • 2
  • 72
  • 109
3

Sorry, but the best I've found on the net is just an overview ( http://www.securitypronews.com/it/applicationdevelopment/spn-19-20020115VisualBasicProjectFilesStructure.html ).

Also note that ActiveX controls used in VB Forms will have reference entries in the *.frm file.

I am guessing you're looking to develop ActiveX projects (whether EXE, DLL, or OCX). If that's your aim, here's my advice:

(1) Learn about the Binary Compatibility settings.

(2) It is good practice to suffix your reference executable with a .cmp, such as Project1.dll.cmp. When you look up Binary Compatibility, you'll know what I mean.

(3) Develop your VB6 ActiveX projects inside of VirtualPC; VB6 ActiveX development puts a lot of wear and tear on the Windows Registry.

(4) The file path to the DLL/EXE/OCX in the Reference= setting will change when VB has reason to locate an ActiveX object; it will go with whatever it finds in the registry (the latest to register wins). Also, there is the "Upgrade ActiveX Controls" setting the Project properties that can make changes.

(5) You have little to no control over the GUID or Type Library that VB6 will generate, except to the degree you can achieve via proper Binary Compatibility management.

Here's what I know - from your example above,

The BF204980-5E29-4945-AEB5-DDB284C568D3 indicates the GUID of the ActiveX object.

The 1.0 indicates the version of the ActiveX object.

The 0 indicates the ... I don't know.

The ..\Project1.dll is the (relative) path to where the ActiveX DLL is (or was) located.

The Project1 is the (friendly) name of the ActiveX object.

rskar
  • 4,607
  • 25
  • 21
  • This info is all good advice. the key is to compile your dll/ocx with compatibility turned OFF, then copy that file to the CMP file, and recompile, with compatibility set to binary, pointed at the CMP file as the reference file (to be compatible with). IF you then break compat for whatever reason, VB will warn you. However, keep in mind that you +can+ change method signatures, or add new methods and not technically break compatibility, but still cause probs down the road with compatibility, so be careful when altering method signatures or adding new methods/properties etc. – DarinH May 24 '11 at 17:28
  • Good answer. there's also the manual although it doesn't explain these references http://msdn.microsoft.com/en-us/library/aa716294(v=VS.60).aspx – MarkJ May 24 '11 at 21:11