LNK2020 using managed/unmanaged classes combination and workaround question

[Gustavo L. Fabro]

Greetings!

I found myself with a LNK2020 linking problem using VS.NET 2003 under a
situation that I was able to replicate in a small project.

I found one workaround for the problem too, but it's ugly and sure things
shouldn't be like that. I'd like to know if that's a conceptual mistake by
me, a compiler error, both, or none of them! ;-)

To replicate the problem:

- Create a new solution with 2 projects:
- The first project will be a DLL (New Project, Win32 Application,
Application Settings, mark 'DLL' and 'Export Symbols'). Name it anything,
say, TestDLL
- For the other project, create a "Windows Forms application"

In the DLL:
- Add to project, besides the default .cpp generated by VS, another one, say
ManagedClassX.cpp
- Define your class like this:

//ManagedClassX.h:
//--------------------------------
public __gc class ManagedClassX
{
public:
void SomeMethod();
};
//--------------------------End of h

//ManagedClassX.cpp:
//--------------------------------
#using <mscorlib.dll>

#include "ManagedClassX.h"

void ManagedClassX::SomeMethod()
{
};
//----------------------------End of cpp

As we can see, this is a managed class added to the DLL.

To the Windows Forms project,

- Add a button to the main form. Add to this button the code:

ManagedClassX* test = new ManagedClassX();
test->SomeMethod();

and make sure that the Form1.h contains

#include "ManagedClassX.h"

All set up, make sure you compile everything with /clr. Yes, I understand
this will create managed code for everything.

At my test machine here, the DLL compiles just fine. But the WinForms
application
that is going to use it no - it gives me an LNK2020 error:

------ Build started: Project: WinForms, Configuration: Release Win32 ------

Compiling...
Form1.cpp
Linking...
LINK : error LNK2020: unresolved token (06000002) ManagedClassX::SomeMethod
LINK : fatal error LNK1120: 1 unresolved externals

How can that be? The class was compiled, the .lib file from the DLL is
already added in my "Additional Dependencies" property for the project...

Everything shoud work fine! Methods exported from the Win32 dll work fine on
my Windows Forms Application. Sure, they are being exported by the
"__declspec(dllexport)" directive, but the managed class is declared
"Public", so the class and its methods should be visible... Shouldn't them?

The Workaround is to add the "ManagedClass.cpp" file inside my "Windows
Forms"
project, and having the project compile again. Then I don't get the
unresolved external and things work. But this has some drawbacks, like
having to compile files twice... Surely it's not the desired solution!

Any clues?

Thank you for any help,

Gustavo Fabro

gu***********************@hotmail.com