In the example above, the problem was due to the fact that BAR did not have a definition in the source tree of the project.
I'm relatively new to TFS and VS, so let me see if I can explain this in a way that makes sense.
The solution has multiple projects. One project is called MatlabDLL
, the main project is called OurLibrary
. The Matlab DLL is not importing all of Library, just wraps parts of it for inclusion into Matlab. In many cases, Matlab DLL can easily call directly to the C functions, in other cases, functions have to be rewritten to handle Matlab C/DLL calling semantics.
So, BAR
had to have a Matlab specific C wrapper around it to enable it to be called from Matlab. The associated source file bar.cpp was in the MatlabDLL project. (Under the hood, BAR
calls a number of functions whose source lives in the OurLibrary
project, none of whose source files are in the MatlabDLL project.)
FOO
had an implementation that did not require a C specific wrapper, so foo.cpp lived in the OurLibrary
part of the source tree, and had no source files in the MatlabDLL
project, although it's associated .h
file was referenced by MatlabDLL.h
.
In the end, VS2010 appears to only build the __declspec(dllexport)
'd functions that have associated c
files in the project. Adding foo.c
to the project fixed the problem.