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

[Duncan Smith]

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.ob j : error LNK2019: unresolved external symbol "public:
long __thiscall ILTIPDataProvid er::DispatchMes sage(struct ILTIPMessage
*)" (?DispatchMessa ge@ILTIPDataPro vider@@QAEJPAUI LTIPMessage@@@Z )
referenced in function "public: void __thiscall
CCommonView::Fe edHistory(void) " (?FeedHistory@C CommonView@@QAE XXZ)
3>Penelope.obj : error LNK2001: unresolved external symbol "public:
long __thiscall ILTIPDataProvid er::DispatchMes sage(struct ILTIPMessage
*)" (?DispatchMessa ge@ILTIPDataPro vider@@QAEJPAUI LTIPMessage@@@Z )

[Bruno van Dooren]

>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

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
br************* *********@hotma il.com

[Duncan Smith]

>
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_v an_doo...@hotma il.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\inc lude
\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

[Duncan Smith]

On Apr 28, 4:16 pm, Duncan Smith <DSmith1...@goo glemail.comwrot e:

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_v an_doo...@hotma il.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\inc lude
\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

Answer is to use #ifdef _MANAGED in the headers.

[Ben Voigt]

"Duncan Smith" <DS********@goo glemail.comwrot e in message
news:11******** **************@ y80g2000hsf.goo glegroups.com.. .

On Apr 28, 4:16 pm, Duncan Smith <DSmith1...@goo glemail.comwrot e:

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_v an_doo...@hotma il.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\inc lude
\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

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).