2009-06-01 7 views
6

Soy nuevo en C++ administrado.Token no resuelto C++ administrado

Tengo dos proyectos administrados de C++ en un archivo .sln, Project Lib y Project LibTest. LibTest hace uso de Lib.

Lib compila y enlaces bien. El proyecto está configurado como .dll.

LibTest también se compila como .dll, pero cuando se trata de vincular, obtengo "token no resuelto" en todos los métodos de Lib ::. Esas definiciones de métodos se definen en el archivo Lib.cpp.

Si moví las definiciones al archivo Lib.h, todo funciona.

Ya he modificado la referencia de LibTest para que dependa del proyecto Lib.

¿Qué me estoy perdiendo?

EDIT: Bien, esto es exactamente lo que tengo y todavía no funciona.

En primer lugar, estoy usando Visual Studio 2008 SP1.

En segundo lugar, cuando hice un ejercicio similar en C#, funcionó bien.

Creé un proyecto C++ CLR vacío. Agregué un proyecto Lib. Agregué una clase administrada. VSTD generó Lib.h y Lib.cpp. El constructor se genera automáticamente.

Luego agregué otro proyecto a mi solución; Lo llamé LibTest. Agregué otra clase administrada llamada LibTest. LibTest.h y LibTest.cpp se generan. He intentado crear una instancia de Lib en el constructor LibTest, pero durante su vinculación simplemente dijo:

1> LibTest.obj: error LNK2020:. Símbolo sin resolver (06000002) Lib :: Héctor

Aquí está el código exacto:

proyecto Lib (compilado como .dll proyecto)

//Lib.h 
#pragma once 

ref class Lib 
{ 
public: 
    Lib(void); 
}; 


//Lib.cpp 
#include "Lib.h" 

Lib::Lib(void) 
{ 
} 

proyecto LibTest (compilado como aplicación.exe)

// LibTest.h 
#pragma once 

ref class LibTest 
{ 
public: 
    LibTest(void); 
}; 

// LibTest.cpp 
#include "LibTest.h" 
#include "Lib.h" 

LibTest::LibTest(void) 
{ 
    Lib^ lib = gcnew Lib; 
} 

int main() 
{ 
    return 0; 
} 
+0

Wow..I debe say..coming no administrado de C++ .. He deseado siempre el entorno de desarrollo (en este caso el VSTD IDE) para administrar el #include y todos los enlaces de la biblioteca sin que yo tenga que especificarlo explícitamente. Esto es bastante sorprendente! ¡Quiero contar todo el mundo de C++ no gestionado de esto! (¡Solo tengo 6 años de retraso! = P) – sivabudh

Respuesta

9

Managed C++ funciona igual que C# con respecto a los tipos en diferentes conjuntos.Lo que esto significa es que es necesario declarar una clase Lib como public:

public ref class Lib 

Y no se debe incluir en su proyecto Lib.hLibTest. Cuando agrega la referencia al proyecto Lib, el compilador podrá resolver cualquier símbolo que se encuentre allí.

Su código actual incluye Lib.h, por lo que el vinculador busca la clase Lib en el ensamblado LibTest y busca allí el constructor.

+0

Gracias, Bojan; problema resuelto. Ojalá pudiera haber votado por ti 10 veces ... pero stackoverflow solo permite 1. ;-) – sivabudh

+1

En cualquier momento, me alegro de que haya sido útil :) –

1

Si está utilizando extensiones administradas, establecer la referencia correctamente debería ser todo lo que necesita.

Si está utilizando funciones estándar de C++, probablemente necesite definir sus funciones usando __declspec(dllexport) y __declspec(dllimport). See MSDN for details.

__declspec(dllexport) es lo que agrega funciones específicas a la biblioteca de exportación, y __declspec(dllimport) le dice a la biblioteca de importación (LibTest) que necesita importar esos símbolos de la DLL.

+0

sí ... todos están administrados. esto es realmente desconcertante. – sivabudh

0

Aquí está la modificación final propuesta por Bojan. Gracias Bojan!

Nota: ¡no olvide agregar "Lib" a su referencia "LibTest"!

Proyecto Lib (compilado como .dll proyecto)

//Lib.h

#pragma once 

public ref class Lib 
{ 
public: 
    Lib(void); 
}; 

//Lib.cpp

#include "Lib.h" 

Lib::Lib(void) 
{ 
} 

Proyecto LibTest (compilado como aplicación .exe)

// LibTest.h

#pragma once 

ref class LibTest 
{ 
public: 
    LibTest(void); 
}; 

// LibTest.cpp

#include "LibTest.h" 

LibTest::LibTest(void) 
{ 
    Lib^ lib = gcnew Lib; 
} 

int main() 
{ 
    return 0; 
} 
Cuestiones relacionadas