GUID update in Visual Basic .VBP and .FRM files

[smckeown]

Hello,

Can anyone shed some light on the magic that either VBP or Visual Basic performs on GUIDs.

I have a Visual Basic group with an executable, and .OCX. The GUID for the OCX appears in the .frm file along with the .vbp file.

Using VBP, the build step are:
-create a reference copy of the ocx
--set 'no compatilbity' before the build
--update the compatibility directory is checked and set
--set poject to binary comp. after building is set
--update the target executable directory for each project is set

When I run VPB, the ocx is build, the guid is rolled, the .vbp is updated with the new GUID, BUT, the .frm has the old guid.

The executable runs and the project opens fine in Visual Basic, but now there is a guid mismatch between the .frm file and the.vbp file.

Thanks,
Sheryl

[smckeown]

Hello,

I thought I had posted in the VBP forum, as that is probably this belongs.

The GUIDs are being rolled by Visual Builder Pro in the build steps outlined. However, it appears that Visual Builder Pro is only setting the GUID from the new .ocx in the .vbp (dot vbp is the visual basic project file). Visual Builder Pro is NOT setting the GUID for the OCX in the .frm (Visual Basic form) file.

Said another way, after the build the Visual Basic .frm file still has the old GUID.

Therefore, after the VBP build, there is mis-matched GUIDs.

The secondary question and far less important is 'why doesn't Visual Basic care?'

So, my question is: Why after the build does Visual Builder Pro not update the GUID in the .frm file?

Thanks,
Sheryl

[kevina]

Fixing up of FRM and OCX references is supported (demonstrated in the VStudio.bld sample). Not sure of the reason for some of the steps you are using (which could actually prevent Visual Build Pro from doing the GUID fixup you desire), you might want to try modeling your build more closely after the VStudio sample.

If following the VStudio.bld sample doesn't resolve your binary compatible issues, please ZIP and send or post:
1) the info from Help | About | Install Info
2) the .bld file used to build
3) a build log file
4) a reproducible test case (VBG+VBPs+source)

[smckeown]

Hello,

Thanks for the reply.

Attached is a zip file with two directories. FromIDE is the ocx project, ocx file, and test project straight from the IDE. The GUIDs match in the FRM and the VBP and match the OCX in bin.

The directory ForVBP contains the build file and group with the project and ocx. The GUIDs don't match, but the GUID from the visual basic project file matches the guid in bin.

There is a file called guidfind in bin that dumps the guid of an ocx or dll to a same named file with the extension .guid. Example: guidfind mycontrol.ocx creates the text file mycontrol.ocx.guid with the guid.

All this being said, the build is working 98% as I expect in that...
-compatibility is broken
-the control is built
-the .vbp is updated with the new guid from the freshly built ocx
-the project is built
-everything runs

The only catch is the frm GUID doesn't match the project guid.

Thanks for any feedback,
Sheryl

PS: I am running VBP 5.7. There is a png in the zip with the Help|About screen shot.

[kinook]

One of your settings in the Make VB6 action (either /outdir in additional options and/or updating the compatibility or target directory) was preventing the action from detecting and fixing up the reference change when building with no compatibility. The attached sample, with those options disabled, builds and updates the reference properly.

Also note that VBP v5 is no longer being supported or enhanced.

[smckeown]

Hi,

Thanks for the update...but this still isn't working for me. I ran the script as uploaded. The control and exe built, but...

...the GUID in visual basic project and visual basic form still don't match. FYI, the GUIDs in the uploaded files don't match either.

Here is the GUID from my build when I opened the zipped file and ran the build step:


GuidTEST.vbp
Object={AC7EEE5E-4A5A-4044-BF12-EE44CB4AC88F}#1.0#0; SampleMessageBar.ocx

frmGuidTest.frm
Object = "{C6CC3716-5AD9-47F8-AB9B-1D2D543947AB}#1.0#0"; "SampleMessageBar.ocx"

When I run the build again the GUID rolls and project file is updated, but the form file is not updated. Here are the results:

GuidTest.vbp
Object={A6D21C65-1A77-49A1-A389-9D1B1C95714A}#1.0#0; SampleMessageBar.ocx

frmGuidTest.frm
Object =
"{C6CC3716-5AD9-47F8-AB9B-1D2D543947AB}#1.0#0"; "SampleMessageBar.ocx"

The test program does run.

Any ideas?

Thanks,
Sheryl

[kinook]

True, the Make VB6 action doesn't actually update the .frm file GUID, but it's unnecessary as the project builds and runs properly.

[smckeown]

Thanks.

So back to my original question, why doesn't Visual Builder Pro update the frm file?



-Sheryl

[kinook]

Originally posted by kinook
...it's unnecessary as the project builds and runs properly.

[smckeown]

Thanks for the response. I really do appreciate the time and effort.

What I am really looking for the technical explanation for WHY the GUIDs do not match.

I was thinking not matching the GUIDs was a Visual Build Pro design decision (or bug) and was most likely based on some bit of Visual Basic or GUID magic that the designers know.

The purpose of my post is to gain technical insight as to WHY Visual Build Pro doesn’t sync the GUIDs. The project 'runs fine' seems a bit like when a programmer says “It runs fine on my machine” in response to a bug report. _grin_

For instance, perhaps the Visual Build Pro or folk or others know some low level internal VB GUID resolution magic.

Or, perhaps there are MSDN or MS posts about this that I haven’t been able to find. (A link would be great).

Or, perhaps Visual Build Pro folk ‘know’ that the GUIDs don’t have to match because “insert a learned Microsoft nugget of wisdom here.”

Thank again for any inputs…
-Sheryl

[kinook]

There's no special technical reason. Since it does work without changing the GUID, the Make VB6 action doesn't go to any extra effort to change it.