C++/CLI and C++ [Mixed] Class Library - project settings

[ajtaylor]

Hello,

I have a load of native C++ code that I want to use in a CLR class
library. My "logic" being that I create a C++/CLI managed class that
acts as an interface to the unmanged code.

I created a new CLR class library and added my native/unmanaged C++
code then added some code to the unmanaged class.

Now, and this is where I am not sure, I turned off the CLR support in
the project settings

Configuration Properties | General | Common Language Runtime support

[I set this to "No Common Language Runtime support"]

and for the .CPP file that contains the managed code I set the

C/C++ | General | Common Language Runtime support

to /CLR.

When I build the project all is fine.

The problem comes when I try to use this assemly in another project I
get an error about a missing .LIB file for the assembly I am trying to
use.

Now I am pretty sure I read somewhere that the turning off of the CLR
option on the project was the correct thing to do when compiling mixed
code.

Can someone out there help me please as yet again C++/CLI is the poor
man interms of documention/books out there*

*depite IMHO being a better solution than using C#

Thanks.

 

[William DePalo [MVP VC++]]

I have a load of native C++ code that I want to use in a CLR class
library. My "logic" being that I create a C++/CLI managed class that
acts as an interface to the unmanged code.

I created a new CLR class library and added my native/unmanaged C++
code then added some code to the unmanaged class.

Now, and this is where I am not sure, I turned off the CLR support in
the project settings

FWIW: In a mixed mode application of mine, I ask for CLR support at the
project level and use

#pragma unmanaged

...

#pragma managed

where I need to turn that off.
is fine.

The problem comes when I try to use this assemly in another project I
get an error about a missing .LIB file for the assembly I am trying to
use.

If you post the exact text of the error message here someone will likely be
able to decipher it for you.

Can someone out there help me please as yet again C++/CLI is the poor
man interms of documention/books out there*

I feel your pain. This book has been in the offing for some time:

http://www.amazon.com/gp/product/0321174054/104-3847305-9675940?v=glance&n=283155

and it is written by one of the big guns on the compiler team I have high
hopes for it. I do hope that it shows up on a bookshelf soon. On that page,
Amazon does have other C++/CLI books which actually exist but I have not
read them.

Regards,
Will

 

[ajtaylor]

FWIW: In a mixed mode application of mine, I ask for CLR support at the
project level and use

#pragma unmanaged

...

#pragma managed

where I need to turn that off.
is fine.



If you post the exact text of the error message here someone will likely be
able to decipher it for you.


I feel your pain. This book has been in the offing for some time:

http://www.amazon.com/gp/product/0321174054/104-3847305-9675940?v=glance&n=283155

and it is written by one of the big guns on the compiler team I have high
hopes for it. I do hope that it shows up on a bookshelf soon. On that page,
Amazon does have other C++/CLI books which actually exist but I have not
read them.

Regards,
Will

The error I get is

2>LINK : fatal error LNK1104: cannot open file
'..\debug\CalculationEngine.lib'

When it is attempting to link the CLR forms application that is
attempting to use the mixed assembly.

*the mixed assembly is called CalculationEngine and the dll is created
ok.

 

[ajtaylor]

FWIW: In a mixed mode application of mine, I ask for CLR support at the
project level and use

#pragma unmanaged

...

#pragma managed

where I need to turn that off.
is fine.



If you post the exact text of the error message here someone will likely be
able to decipher it for you.


I feel your pain. This book has been in the offing for some time:

http://www.amazon.com/gp/product/0321174054/104-3847305-9675940?v=glance&n=283155

and it is written by one of the big guns on the compiler team I have high
hopes for it. I do hope that it shows up on a bookshelf soon. On that page,
Amazon does have other C++/CLI books which actually exist but I have not
read them.

Regards,
Will

Note I am currently using this book:

Pro Visual C++/CLI and the .NET 2.0 Platform (Hardcover)

for reference as it seems to be the only one on the subject that is
available at the moment.

 

[William DePalo [MVP VC++]]

The error I get is

2>LINK : fatal error LNK1104: cannot open file
'..\debug\CalculationEngine.lib'

When it is attempting to link the CLR forms application that is
attempting to use the mixed assembly.

*the mixed assembly is called CalculationEngine and the dll is created
ok.

At the risk of repeating the obvious, choose Options from the Tools menu.
Then navigate

Project and Solutions -> VC++ Directories

Select Library Files in the combo box labeled "Show directories for" and
make sure that the directory containing your library is listed there.

Regards,
Will

 

[ajtaylor]

At the risk of repeating the obvious, choose Options from the Tools menu.
Then navigate

Project and Solutions -> VC++ Directories

Select Library Files in the combo box labeled "Show directories for" and
make sure that the directory containing your library is listed there.

Regards,
Will

Many thanks for your reply but my [all be it poor] understanding is
that I am creating a Mixed (Native and Managed) assembly
[CalculationEngine.dll] and as such there should not be a .lib file
produced!

 

[William DePalo [MVP VC++]]

Many thanks for your reply

You are welcome.

but my [all be it poor] understanding is
that I am creating a Mixed (Native and Managed) assembly
[CalculationEngine.dll] and as such there should not be a .lib file
produced!

I might be wrong, but it looked to me like you added

CalculationEngine.lib

as a dependency and it looked like the linker could not find it. The
procedure that I sketched addresses that problem.

Regards,
Will

 

[ajtaylor]

Many thanks for your reply

You are welcome.

but my [all be it poor] understanding is
that I am creating a Mixed (Native and Managed) assembly
[CalculationEngine.dll] and as such there should not be a .lib file
produced!

I might be wrong, but it looked to me like you added

CalculationEngine.lib

as a dependency and it looked like the linker could not find it. The
procedure that I sketched addresses that problem.

Regards,
Will

Having done some testing it appears the issue is this.

If I create a CLR Class library project and for all the native /
unmanaged C++ files set them TO NOT USE CLR then all works fine.

If I make the project not use CLR and only set the managed files to use
CLR then I get the link error

As there are a lot of C++ native/unmanaged files I decided the 2nd
approach was less time consuming.

I am basing my approach [the only using CLR compilation option on the
managed files] on stuff I have read on the internet including

http://msdn.microsoft.com/msdnmag/issues/06/05/MixAndMatch/default.aspx

and a presentation the author has on his personal website where he
shows that a C++ project can use managed code by simply flicking the
CLR compilation switch on that file.

I sort of understand why the linker is expecting a lib file as I
suppose by making the project settings not to use CLR then it looks
like a normal dll project.

What I dont understand is that if there is some unmanged code in the
project then surely the output is an .NET assembly and thus there is no
lib file.

*Confused*

 

[Tarek Madkour [Microsoft]]

(e-mail address removed) wrote in

If I make the project not use CLR and only set the managed files to
use CLR then I get the link error

[...]

I sort of understand why the linker is expecting a lib file as I
suppose by making the project settings not to use CLR then it looks
like a normal dll project.

What I dont understand is that if there is some unmanged code in the
project then surely the output is an .NET assembly and thus there is
no lib file.

You are hitting a "bug" in the Visual C++ build system. We are not
supposed to try to link in an import library when the dependent DLL is
a managed DLL with no native exports.

However, there are a couple of reason why this "bug" exists. There are
also some workarounds that you can use.

Let me start with the reasons why this "bug" exists:

1. In a mixed-mode DLL, you can actually have both managed and native
exports. If you had native exports, we would need the import library. We
can't tell if you have native exports unless we inspect the binary.
Inspecting the binary is something that we currently do not do and would
be quite a significant change in how the build system works.

2. To determine that a DLL is a mixed-mode DLL when the project says
that /clr is not being used, we'd have to inspect the options on every
file in the project to see if any file has /clr. This will need to be
done on every build and can be quite expensive (imagine projects with
thousands of files). It will slow down the build for the standard "i'm
building a large native DLL" case which we consider an "evil" thing.

Ok. So what is the workaround? On the general linker settings page of
the consuming project, set "Link Library Dependencies" to "No". This
will have the effect of not linking the import library (which is what
you want) but will also have the effect of not linking in any static or
import libraries that this project depends on (which is probably not
what you want). To avoid the latter side-effect, you'll need to manually
add any dependent libraries you want linked in on the linker line
manually.

I hope this helps.

Thanks,
Tarek Madkour
Lead Program Manager
Microsoft Visual C++

 

[ajtaylor]

(e-mail address removed) wrote in

If I make the project not use CLR and only set the managed files to
use CLR then I get the link error

[...]

I sort of understand why the linker is expecting a lib file as I
suppose by making the project settings not to use CLR then it looks
like a normal dll project.

What I dont understand is that if there is some unmanged code in the
project then surely the output is an .NET assembly and thus there is
no lib file.

You are hitting a "bug" in the Visual C++ build system. We are not
supposed to try to link in an import library when the dependent DLL is
a managed DLL with no native exports.

However, there are a couple of reason why this "bug" exists. There are
also some workarounds that you can use.

Let me start with the reasons why this "bug" exists:

1. In a mixed-mode DLL, you can actually have both managed and native
exports. If you had native exports, we would need the import library. We
can't tell if you have native exports unless we inspect the binary.
Inspecting the binary is something that we currently do not do and would
be quite a significant change in how the build system works.

2. To determine that a DLL is a mixed-mode DLL when the project says
that /clr is not being used, we'd have to inspect the options on every
file in the project to see if any file has /clr. This will need to be
done on every build and can be quite expensive (imagine projects with
thousands of files). It will slow down the build for the standard "i'm
building a large native DLL" case which we consider an "evil" thing.

Ok. So what is the workaround? On the general linker settings page of
the consuming project, set "Link Library Dependencies" to "No". This
will have the effect of not linking the import library (which is what
you want) but will also have the effect of not linking in any static or
import libraries that this project depends on (which is probably not
what you want). To avoid the latter side-effect, you'll need to manually
add any dependent libraries you want linked in on the linker line
manually.

I hope this helps.

Thanks,
Tarek Madkour
Lead Program Manager
Microsoft Visual C++

Many thanks for the reply. As a matter of interest is this information
on the Microsoft website anywhere - if not perhaps it should be.

On a final note - is there any issue with making the project settings
use CLR and then making all the native C++ files settings to not use
CLR?

 

[Tarek Madkour [Microsoft]]

(e-mail address removed) wrote in @m79g2000cwm.googlegroups.com:

You are hitting a "bug" in the Visual C++ build system. We are not
supposed to try to link in an import library when the dependent DLL is
a managed DLL with no native exports.

However, there are a couple of reason why this "bug" exists. There are
also some workarounds that you can use.

[...]

Many thanks for the reply. As a matter of interest is this information
on the Microsoft website anywhere - if not perhaps it should be.

It's not . I'll contact our support team to get a KB article out for it.

On a final note - is there any issue with making the project settings
use CLR and then making all the native C++ files settings to not use
CLR?

No. It makes the IDE happier but may be harder for you to maintain if you
have way more native sources than you have managed ones.

Thanks,
Tarek Madkour