Using TFS 2013, VB6, Windows Server 2008R2
Problem:
While performing a TFS build of a VB6 application, I am receiving an error "Compile error in file c:\builds\clsCommon.cls Line 122:Can'tfind project or library"
Setup:
I have three projects: two VB6 dll's and one vb.net COM Callable Wrapper (CCW) dll. The first project (VB6) is called MyBase.dll. When I issue a make from the IDE, it complies and builds the dll. When I perform a build from TFS, again it builds without issue.
Next, is my .net assembly. Lets just say it complies and I'm able to compile other applications with it as a reference. In fact, let me state that I can compile my entire suite of applications and they work when I build them from the IDE. The problem is when I build from TFS
Finally I build the next VB6 project using TFS. This DLL (Called batch) internally references myBase.dll. Inside my batch project I have a class called clsCommon.cls. At line number 122 inside clsCommon I instantiate an object based on myBase.clsLOGs. Now when I run the TFS build, I get the error that Batch.clsCommon can not find myBase.clsLOGs:
Private g_ErrorLogs AS MyBase.clsLOGs '<---- Line 122 of Batch.clsCommon
That is the nuts and bolts of it.
What I have tried:
Compatibility mode is turned off. I tried to set it to Binary Compatibility, but I get an error that I can't set Compatibility Mode.
All of out DLL's and EXE's are moved into a common executable folder D:\PEEPS\bin. When we set references in the IDE, we point to D:\PEEPS\bin. In TFS, the builds drop into C:\builds.
IDE Builds drop into D:\PEEPS\bin
Project references look in D:\PEEPS\bin
TFS builds and drops into C:\builds
Why are we doing builds in TFS if makes from the IDE are working?
Also, to circumvent the issue in the past, we simply took the builds from the developers IDE and gave it to QA for testing. If everything tested ok, QA gave it to production support for implementation. The problem with that solution is our industry regulators do not want developers to give production EXE's and DLL's to QA or Production Support. They have to be able to perform their own builds and TFS is our code repository.
Thank you in advance for you help.
![]( "Cry")
HaYen
Problem:
While performing a TFS build of a VB6 application, I am receiving an error "Compile error in file c:\builds\clsCommon.cls Line 122:Can'tfind project or library"
Setup:
I have three projects: two VB6 dll's and one vb.net COM Callable Wrapper (CCW) dll. The first project (VB6) is called MyBase.dll. When I issue a make from the IDE, it complies and builds the dll. When I perform a build from TFS, again it builds without issue.
Next, is my .net assembly. Lets just say it complies and I'm able to compile other applications with it as a reference. In fact, let me state that I can compile my entire suite of applications and they work when I build them from the IDE. The problem is when I build from TFS
Finally I build the next VB6 project using TFS. This DLL (Called batch) internally references myBase.dll. Inside my batch project I have a class called clsCommon.cls. At line number 122 inside clsCommon I instantiate an object based on myBase.clsLOGs. Now when I run the TFS build, I get the error that Batch.clsCommon can not find myBase.clsLOGs:
Private g_ErrorLogs AS MyBase.clsLOGs '<---- Line 122 of Batch.clsCommon
That is the nuts and bolts of it.
What I have tried:
Compatibility mode is turned off. I tried to set it to Binary Compatibility, but I get an error that I can't set Compatibility Mode.
All of out DLL's and EXE's are moved into a common executable folder D:\PEEPS\bin. When we set references in the IDE, we point to D:\PEEPS\bin. In TFS, the builds drop into C:\builds.
IDE Builds drop into D:\PEEPS\bin
Project references look in D:\PEEPS\bin
TFS builds and drops into C:\builds
Why are we doing builds in TFS if makes from the IDE are working?
Also, to circumvent the issue in the past, we simply took the builds from the developers IDE and gave it to QA for testing. If everything tested ok, QA gave it to production support for implementation. The problem with that solution is our industry regulators do not want developers to give production EXE's and DLL's to QA or Production Support. They have to be able to perform their own builds and TFS is our code repository.
Thank you in advance for you help.
HaYenBJK1