|
#1
|
|||
|
|||
VB projects and component references
This is more of a VB issue but is affecting our Visual Build process...
We have a team of developers working on a VB app that comprises a number of VB components. All components are rebuilt as part of the build process for the main project. We register each component on the build machine as it is built. It seems that a VB project file (.vbp) stores the path of any components that a project uses. When a developer opens this file in their VB IDE these paths seem to get automatically updated to the location of those components on the developer's machine (VB must read the system registry to do this). This means that Developer1 might check-in a .vbp containing component paths specific to their machine. When Developer2 then does a GetLatest on this project and opens .vbp in their IDE the paths get autmotically updated to match the COM registration information on their machine. So no problem, Developer2 can still compile the project. Unfortunately though, Visual Build doesn’t use the VB IDE and so the paths never get automatically updated. This means that the VB compiler on the Visual Build machine attempts to use the paths that were set by the last developer to check-in the .vbp file. If the paths are different the action fails. This is causing us a lot of problems and so I am wondering if their is anyway to force the Make VB6 action to either update the paths or allow specific paths to be defined for component? |
#2
|
|||
|
|||
The path to a reference is only a hint; the VB6 compiler will actually resolve the reference by looking up the reference typelib GUID in the registry, so as long as the component containing the matching typelib has been registered, it will be able to find it even if the hint path is incorrect.
|
#3
|
|||
|
|||
Really??
These are the steps to reproduce and workaround the problem: Step 1. Run a VisualBuild script that attempts to compile MyProject.vbp. It fails and reports that it can't find a component. Step 2. Imediately open MyProject.vbp in the VB IDE and compile. This time it will compile successfully. At this point MyProject.vbp has also been updated to point to the correct location of the registered components it uses. Since I've not performed any re-registration of components between Steps #1 and #2 doesn't it imply that its the file locations in MyProject.vbp that are used by the command line compiler? Also if I check-in MyProject.vbp after step 2 and re-run the VisualBuild script it compiles successfully. Again, no re-registration of components. |
#4
|
|||
|
|||
That's really weird. I tried completing removing the filename in the reference to SecondVB in the FirstVB.vbp sample project (Samples\VStudio\orig\Source\FirstVB) like so:
Reference=*\G{287F3C8B-089A-11D4-A442-444553540001}#1.0#0##SecondVB then registered SecondVB.dll and ThirdVB.ocx (the 2 external references the project has), built FirstVB.vbp from a Make VB6 action, and it built successfully. (It also worked with a bogus filename in the reference line.) I have no idea why it doesn't work for you. Is the error coming from the VB compiler or the Make VB6 action (check the 'show command-line' checkbox on the Options tab, rebuild, and post the build log)? |
|
|