Hi
I hope someone can help me with this, as we are evalutaing FB and this could clinch it…
We have a large n-tier VB6 project. All components are set to use binary compatibilty, and we break it fairly regularly. When we do this the component in question is rebuilt first with no compatibilty set, and then with binary set to regenerate new guids.
Our current build process relies on a manual search and replace to update all of the .vbps that reference the "broken " component with the new guid.
Is there a way round this in FB? I thought that “Fix Up ActiveX references” would achive this, but the documentation seems to suggest that it only applies to “No” and “Project” compatibilty, and attmepting to use it it gives the message “Attempting to find in registry” and “Could not resolve reference to…”. The component it is looking for has been built and registered as part of a previous step.
Any ideas welcome…
TIA
Matt
Hi Matt
Dealing with broken references in VB projects is nearly always problematic. The fixup references option attempts to do the following :
Parse the reference string in the vbp file, extract the filename, check if the file exists
(it might not if the reference was created on another machine with different installtion paths, system folders etc)
if the file does not exist
look in the registry under HKEY_CLASSES_ROOT\Typelib and see if there is an entry for the typelib
if there is an entry read the default value from the win32 subkey which will provide the location of the dll
load the type library in the referenced file using TLBINF32.DLL
check if the guid in the reference string matches that of the type library
if not then update the reference line with the correct guid
Also check the typelib major & minor version numbers and update the reference accordingly.
This process works quite well, except when there are circular references between vbp’s. I’m afraid I can’t guarantee a perfect solution for your projects. The only thing I can suggest is that you setup the actions for the projects in the best order for building and then turn on the fixup references option where needed.
HI,
I have some kind of similar problem. I compile vb6 projects with binary competible always. When binary competibility breaks error occurs on Finalbuilder and it shows in build log. There should be a way that when I know binary competibility is breaking I should select an option somewhere which could compile the project breaking competibility.
Actually on VB6 when a prompt occurs asking to break binary competibility finalbuilder exists the compilation. Is there any workaround other then compiling with project competible first then binary competible.
Regards,
Arman Anwar
Systems Limited
Someone has clicked the Alert button on this thread (it’s supposed to be used for alerting us of “profanity” in the message)… we actually would prefer not to have the button at all but it’s built into the forum software…
but, we don’t get any information on the alert, so please reply here if you want to continue the discussion, thanks.
.t8
Yes, I want to continue.
Actually on VB6 when a prompt occurs asking to break binary competibility finalbuilder exists the compilation. Is there any workaround other then compiling with project competible first then binary competible.
We don’t know of any workaround for this, I believe it’s a limitation of VB. Maybe you could ask on a VB forum or maybe other VB users here may have more information for you.
Hi,
I am evaluating the new version of FinalBuilder and I can’t get the Fix Up ActiveX References to work correctly for my VB projects.
Currently the file paths in the VBP file are different since they were created on another system with different installation paths.
According to an earlier post, the Fix Up ActiveX references will do the following:
1. Parse the reference string in the vbp file, extract the filename, check if the file exists
(in my case the file is in a different path
therefore
look in the registry under HKEY_CLASSES_ROOT\Typelib and see if there is an entry for the typelib.
if there is an entry read the default value from the win32 subkey which will provide the location of the dll (I verified the registry and i located the entry and I have the
new path)
load the type library in the referenced file using TLBINF32.DLL
check if the guid in the reference string matches that of the type library
if not then update the reference line with the correct guid
Also check the typelib major & minor version numbers and update the reference accordingly.
For some reason it doesn’t want to update the reference.
The build is always giving me the following errors:
Referenced TypeLib : …\filename.dll - does not exist!
Attempting to find typelib in registry…
Error Fixing up References : Could not resolve reference to : …\Projects\filename.dll
Thanks
Hi Gerry
It’s been many years since we had any support requests for the VB action! I don’t have VB6 installed here at the moment so it’s difficult to test this, but the reference fixup code was a desperate attempt to fix a major shortcoming in VB6, and it was never 100% reliable. It’s also very reliant on building the projects in the right order.
I had a look through the code for this action and it’s not been touched for 12 years (other than some housekeeping due to other architecture changes).
I added some more logging to the fixup references code so we can get a clearer picture of what’s going on.
http://downloads.finalbuilder.com/downloads/finalbuilder/800/FB800_2389.exe
Hi Vincent,
Thank you very much. I have applied the update and I am now getting the following error:
Getting absolute path from :…\Projects\filename.dll
Absolute path resolved to :C:\Projects\filename.dll
Checking for already resolved references
Referenced TypeLib : C:\Projects\filename.dll - does not exist!
Attempting to find typelib in registry…
Checking registry key : TypeLib{C20417E9-5749-4499-B1CA-BCC92E454412}\1.0\0\win32
Error Fixing up References : Could not resolve reference to : …\Projects\filename.dll
Error Running Generating Temp VBP File
I checked the Registry and the actual path should be:
TypeLib{C20417E9-5749-4499-B1CA-BCC92E454412}<strong>1.1\0\win32
Thanks
Gerry
Hi Gerry
The reason it’s checking for 1.0 is that is what is in the reference, which probably looks something like this in the vbp file :
Reference=*\G{C20417E9-5749-4499-B1CA-BCC92E454412}#1.0#0#…\Projects\filename.dll#Microsoft Scripting Runtime
We are literally parsing this line to get :
CLSID
Version (major.minor)
Path
All we can do is fix the pathing issue, if the referenced typelib+version is registered. If it’s a different version, we have no way of determining what the correct version is to select. You will need to update the reference in the vbp file to point to the correct version.