Here's the situation:
I have one VS2005 solution with two projects: MyDll (DLL), MyDllUnitTest (console EXE).
In MyDll I have a class called MyClass which is internal to the DLL and should not be exported. I want to test it in MyDllUnitTest, so I added a test suite class called MyClassTest, where I create instances of MyClass and test them.
My question: how can I link the object file of MyClass, created by building MyDll, to the MyDllUnitTest EXE? I don't want to build MyClass in MyDllUnitTest and I don't want to export the class.
I tried using the same Intermediate Directory for both projects (so object files are in the same directory) and using the References feature of VS2005 (right click project --> References --> Add New Reference...), but it didn't work - I still get a linking error (LNK2001).
Edit: I don't want to have the same source file in two projects - consider the face that I have many MyClass/MyClassTest, which means I have to duplicate each MyClass to a different project. I know it is possible to use the same object file in two projects, I've seen it done before but forgot how.
Edit: I've decided to put the files in both projects, so they are compiled twice. It turns out the "Reference" feature works automatically - but only for static lib projects.
I don't understand why you don't want to build it in your dll project. As long as both projects are using the same source file, they will both generate the same object file (assuming compiler options are set the same way).
If you want to test the dll without exporting the class itself (I presume this is because exporting classes in a dll is usually a bad idea), consider exporting a "factory" function from the dll. It would have a signature like:
extern "C" MyClass *CreateMyClass();
This function would create an object of MyClass and return a pointer to it. Your unit test can then do whatever it needs with the returned class object.
Here is an alternative approach to achieve what your trying to do BUT I believe that it will meet your requirements...
Use the InternalsVisibleToAttribute attribute on the assembly that contains the classes you want to test. Then if you reference this assembly you'll be able to test the class even though to other assemblies these types are "invisible". Magic!
Here is the MSDN reference of the attribute to use ...
What I do here is making an extra 'filter' "Object Files" in the testing project, alongside the "Header Files" and "Source Files", and putting all the necessary .obj files in there (which is easier if they've already been generated, by the way). This seems to work fine here. We also use that for unit testing here, and in some places for not having to compile the same source file twice when using it for two different DLLs.
One reason we're doing it this way is that we use CMake to generate our project files, and so cannot use all of the internal Visual Studio 'magic'.
I think you also need to explicitly add the .obj file to your list of additional dependencies in your project linker settings.
you could also try to use a command that generates a .lib with all the objects.
Like in the answer from: Visual C++ link generated objs from referenced project
来源:https://stackoverflow.com/questions/261518/reusing-object-files-in-visual-studio-2005