BUG: Visual Workbench Does Not Use .LIB Files as Dependents

Last reviewed: July 22, 1997
Article ID: Q116485
1.00 1.50 WINDOWS kbtool kbbuglist

The information in this article applies to:

  • The Visual Workbench included with: Microsoft Visual C++ for Windows, versions 1.0 and 1.5

SYMPTOMS

The Microsoft Visual Workbench creates project (.MAK) files based on the individual files added to the project. These project files include dependencies of the target file (.EXE, DLL, and so forth). If a dependency file is modified and its time stamp is later then the target file, the Visual Workbench should rebuild the target. Under the following conditions, the rebuild does not occur when it should:

  • The makefile is generated by Visual C++ and has been opened as an external makefile in the Visual Workbench.

    -or-

  • The same makefile is built using the external utility, NMAKE.EXE, from the MS-DOS prompt.

    -or-

  • The newly modified file is a .LIB file that is specified in the list of the project files by choosing Edit from the Project menu.

Under the above circumstances, choosing to build the project does not cause the project to relink even though a library file has been modified.

However, if the same makefile is opened as an internal makefile in the Visual Workbench and the Build option is chosen from the Project menu, the project is linked again as it should be because a .LIB file has been modified.

CAUSE

If a library file is added to the project list of files rather than being added as a linker option, the Visual Workbench adds the library to the makefile, but the library is not set as a dependency of the project's (.EXE, DLL, and so forth) target file. The make engine used by the Visual Workbench for internal makefiles is not the same as the NMAKE.EXE utility. (The NMAKE.EXE utility is invoked for external makefiles by the Visual Workbench.)

RESOLUTION

There are two possible workarounds to this problem:

  • If the .LIB file is not "code complete", add the .OBJ files that make up the library file to the project's list of files by using the Edit option on the Project menu instead of the .LIB file.

    -or-

  • Edit the makefile using the Visual Workbench or any other editor. Add the $(LIBS_EXT) macro to the $(PROJECT).EXE dependency block, which causes NMAKE to use the library as a dependency. The Visual Workbench accepts this minor change to the makefile. However, a shortcoming to this method is that the change disappears when you choose Scan All Dependencies from the Project menu.

    An example of the dependency line is shown below:

          $(PROJ).EXE:: TEST.OBJ $(OBJS_EXT) $(DEFFILE)
    

    Adding the library dependency results in the above line being changed to the following:

          $(PROJ).EXE:: TEST.OBJ $(OBJS_EXT) $(DEFFILE) $(LIBS_EXT)
    

STATUS

Microsoft has confirmed this to be a bug with the Visual Workbench, versions 1.0 and 1.5. We are researching the problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

This is not a problem with either Visual C++ 32-bit Edition.


Additional reference words: 1.00 1.50
KBCategory: kbtool kbbuglist
KBSubcategory: VWBIss
Keywords : kb16bitonly


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: July 22, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.