Importing a type library into unmanaged code with /clr switch

Importing a type library into unmanaged code with /clr switch - linker errors

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Duncan Smith - 27 Apr 2007 17:53 GMT

I have a VS2005 C++ MFC project which #imports a type library. The
goal is to introduce some managed code eventually, but for starters I
just need to set the /clr compiler option and build the project.

The type library is imported like so:

#import <LtipClient.tlb> no_namespace named_guids

With the /clr switch on, I got lots of LNK2028 errors, so I added the
following directive to the top of each cpp source file

#pragma unmanaged

and I now get lots of LNK2001 and LNK2019 linker errors (see below)

I thought that unmanaged code should be able to use the COM objects as
normal? If I remove the /clr switch the project compiles just fine..

3>CommonView.obj : error LNK2019: unresolved external symbol "public:
long __thiscall ILTIPDataProvider::DispatchMessage(struct ILTIPMessage
*)" (?DispatchMessage@ILTIPDataProvider@@QAEJPAUILTIPMessage@@@Z)
referenced in function "public: void __thiscall
CCommonView::FeedHistory(void)" (?FeedHistory@CCommonView@@QAEXXZ)
3>Penelope.obj : error LNK2001: unresolved external symbol "public:
long __thiscall ILTIPDataProvider::DispatchMessage(struct ILTIPMessage
*)" (?DispatchMessage@ILTIPDataProvider@@QAEJPAUILTIPMessage@@@Z)

Reply to this Message

Bruno van Dooren - 28 Apr 2007 08:23 GMT

>I have a VS2005 C++ MFC project which #imports a type library. The
> goal is to introduce some managed code eventually, but for starters I
[quoted text clipped - 8 lines]
>
> #pragma unmanaged

Hi,

The best practise with /clr is to only define it for individual files. No
for whole projects. This can lead to a multitude of problems.
You also should not use #pragma unmanaged. source files should be wholly
compiled either managed or unmanaged, but not mixed. Doing so can lead to
CRT initialization problems.

Kind regards,
Bruno van Dooren MVP - VC++
http://msmvps.com/blogs/vanDooren
bruno_nos_pam_van_dooren@hotmail.com

Reply to this Message

Duncan Smith - 28 Apr 2007 16:16 GMT

> Hi,
>
[quoted text clipped - 8 lines]
> http://msmvps.com/blogs/vanDooren
> bruno_nos_pam_van_doo...@hotmail.com

Thanks,

I made some progress by just enabling /clr on the module (cpp file)
only, but when I add managed code into the header file like:

#include <afxwinforms.h>

using namespace System;
using namespace System::Windows::Forms;

I get the compiler error:

3>C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include
\afxwinforms.h(19) : fatal error C1189: #error : MFC WinForms support
requires /clr (doesn't support oldSyntax)

How do I enable /clr for the header as well as the cpp without
applying it to the whole project?

Many thanks,

Duncan

Reply to this Message

Duncan Smith - 29 Apr 2007 15:57 GMT

> > Hi,
>
[quoted text clipped - 31 lines]
>
> Duncan

Answer is to use #ifdef _MANAGED in the headers.

Reply to this Message

Ben Voigt - 07 May 2007 15:32 GMT

>> > Hi,
>>
[quoted text clipped - 36 lines]
>
> Answer is to use #ifdef _MANAGED in the headers.

If I understand your problem correctly, you are trying to include all your
headers in one place to use as a precompiler header (stdafx.h perhaps)? If
that is the case, then #ifdef _MANAGED isn't going to help. Precompiled
headers shouldn't be shared between modules compiled with significantly
different options, such as with and without /clr. You could create two
precompiled headers, or turn them off for half the program (or off
entirely).

Reply to this Message

Importing a type library into unmanaged code with /clr switch - linker errors

Free Magazines