views:

81

answers:

1

I have a project that is built with native C++, as well as C++/CLI. I have the following components:

Assembly A  (C++/CLI)
 | uses
Assembly B  (C++/CLI)
 | uses
Static Lib C (Native C++)

I did a major re-write of Static Lib C, and it compiles, and other native projects that use it compile fine as well. None of Assembly B changed in the re-write - and as expected, when I compile Assembly B it compiles fine with no errors or warnings. However, when I try to compile Assembly A, none of the symbols that are supposed to be available in Assembly B can be found, causing hundreds of errors. I tried adding and removing B and C as references in the A project with no luck. I tried doing a clean, and rebuilding everything from scratch - but still no luck. I loaded Assembly B up in RedGate's Reflector, and I can not see the symbols, so at least that's consistent. I'm working on a branch, so I loaded an earlier version of Assembly B from the trunk, (and it asked to unload the previous version I had loaded from my branch), and I could see all the symbols in it. So when I look at my current version of Assembly B in Reflector, I see:

+TFModelSetNETD, Version=1.0.3532.42171, Culture=neutral, PublicKeyToken=null
  +TFModelSetNETD.dll
    + References
      + {} -
      + <CppImplementationDetails>
      + <CrtImplementationDetails>
      + vc_attributes

And that is all. In the older version, I see these four entries, plus all my namespaces declared in Assembly B, Static Lib C, other libs, plus several boost and std namespaces. I should mention this is in Visual Studio 2008.

Any ideas as to what is going on here? I just can't understand what I could have done to make the compiler not export any symbols, without giving me any kind of warning.

Ideas, tips, or debugging suggestions are all greatly appreciated.

Edit: I have loaded the Static Lib C into LibDump, and all the symbols are there - however, none of the symbols either defined in Assembly B, or referenced from Static Lib C are visible in Assembly B when examining it with Redgate Reflector.

A: 

What happened was that the header files for the symbols in question were never being included in a cpp file anywhere. The only explanation I have for why it worked is that maybe one of the other compilation units included the headers in question indirectly, but when it changed in the rewrite, the symbols were no longer being included anywhere. Believe it or not this problem was easy compared to the next one I hit - boost::thread causing the assembly to throw an exception on load because of conflicts relating to DLL initialization and thread-local storage.

Brian Stewart