views:

505

answers:

2

I'm trying to write a mixed-mode DLL, let's call it 'Client', to replace some unmanaged classes with their managed equivalents. Everything works fine on my personal machine, but when I check the source code in, our build machine won't build the project. It doesn't recognize the Managed classes I'm using from another DLL, called 'Core.'

I think the issue has to do with precompiled headers. Here's why:

To use the classes from 'Core', I added a reference to the 'Core' project in the 'Client' Project. If I remove this reference and then build the project on my personal machine, it still works. The CLR PCH doesn't recompile after removing the reference, though. If I recompile the CLR PCH, and then compile the project, it fails with the same errors that I get on the build machine: the managed classes are not recognized.

It seems to me that the managed classes from DLL's you import are defined in the precompiled header. I haven't been able to verify this, but that's the best guess I have. Does anyone have any insight they can shed on this issue? Are project references in Mixed DLL's resolved by putting hooks into the managed PCH?

Steps to Reproduce

The following makes no sense to me:

  1. Get Client to build.
  2. Remove the Reference from Client to Core. Compile Client. Client STILL builds. This is not expected.
  3. Recompile the Client PCH, then compile Client. Compile Client fails: the classes in 'Core' are undefined. This is expected behavior.
  4. Add Reference to Core, compile. Compile Client fails for the same reason. This is not expected
  5. Recompile the Client PCH, then compile Client. Client compiles fine.

My conclusion from this experiment is that the References are inserted into the project via precompiled headers, and that something is broken with the way this works, at least on our build machine.

A: 

It can't work like that can it, because you don't need to use a precompiled header.
All a PCH does is allow you to speed up the build.
It doesn't do anything special with references.....

demoncodemonkey
Every once and a while, when compiling, I can an error:#using failed on "...Core.dll"When I double click htis error it points me to the PCH's cpp file. That's why I think it puts the references into the PCH.
Mark P Neyer
Then what would it do if your project didn't have a PCH at all? Are you sure you have your project dependencies set up correctly? i.e. project Client depends on project Core. Also could this be a Debug/Release problem? Check out http://support.microsoft.com/kb/843407
demoncodemonkey
It's definitely not a debug/release problem. The 'Project References' tab ignores debug vs release mode.
Mark P Neyer
The Microsoft suppport article you supplied didn't apply to my position, because the problem I get on the build machine isn't that a '#using fails', it's that it says class, 'Entry' defined in Core.dll, is not defined.
Mark P Neyer
It might have been helpful if you had put all this extra information in your original question. For the record, you did say that you get a "#using failed" error, so my link was totally relevant. Sheesh. This whole question is so unclear I just wish I'd left it alone ¬_¬ Anyway the PCH is obviously not your problem.
demoncodemonkey
A: 

There is another way to add references to a managed / mixed mode dll in C++/CLI - it's to add #using Core.dll to Client. This might solve your build problem.

Juozas Kontvainis