ID: Q116485
1.00 1.50 WINDOWS kbtool kbbuglist
The information in this article applies to:
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:
-or-
-or-
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.
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.)
There are two possible workarounds to this problem:
-or-
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)
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
Last Reviewed: July 23, 1997