/clr option for VC++ 2005

[WXS]

In VS2003 using /clr meant that you could not use declspec import/export to
import or export methods from a .dll so they could be used externally thus
requiring you to wrap a class using managed code and the /clr option with a
class that did not use that option.

Is the same true for VS2005 or has that issue been resolved?

[Carl Daniel [VC++ MVP]]

"WXS" <WX*@discussions.microsoft.com> wrote in message
news:70**********************************@microsof t.com...

In VS2003 using /clr meant that you could not use declspec import/export
to
import or export methods from a .dll so they could be used externally thus
requiring you to wrap a class using managed code and the /clr option with
a
class that did not use that option.

Is the same true for VS2005 or has that issue been resolved?

The situation is unchanged - you can't export a managed entry point, so if
you have managed code that you want to expose via DLL exports (which are
purely an unmanaged concept), you'll have to write an unmanaged wrapper over
your managed code and export that wrapper.

-cd

[Carl Daniel [VC++ MVP]]

"WXS" <WX*@discussions.microsoft.com> wrote in message
news:70**********************************@microsof t.com...

In VS2003 using /clr meant that you could not use declspec import/export
to
import or export methods from a .dll so they could be used externally thus
requiring you to wrap a class using managed code and the /clr option with
a
class that did not use that option.

Is the same true for VS2005 or has that issue been resolved?

The situation is unchanged - you can't export a managed entry point, so if
you have managed code that you want to expose via DLL exports (which are
purely an unmanaged concept), you'll have to write an unmanaged wrapper over
your managed code and export that wrapper.

-cd

[WXS]

Thanks. I guess it makes sense, unfortunately we make heavy use of declspec
import/export as everything is a .dll so we would need to create wrappers for
every usage of managed code to avoid having to compile the majority of code
with the /clr option.

"Carl Daniel [VC++ MVP]" wrote:

"WXS" <WX*@discussions.microsoft.com> wrote in message
news:70**********************************@microsof t.com...

In VS2003 using /clr meant that you could not use declspec import/export
to
import or export methods from a .dll so they could be used externally thus
requiring you to wrap a class using managed code and the /clr option with
a
class that did not use that option.

Is the same true for VS2005 or has that issue been resolved?

The situation is unchanged - you can't export a managed entry point, so if
you have managed code that you want to expose via DLL exports (which are
purely an unmanaged concept), you'll have to write an unmanaged wrapper over
your managed code and export that wrapper.

-cd

[WXS]

Thanks. I guess it makes sense, unfortunately we make heavy use of declspec
import/export as everything is a .dll so we would need to create wrappers for
every usage of managed code to avoid having to compile the majority of code
with the /clr option.

"Carl Daniel [VC++ MVP]" wrote:

"WXS" <WX*@discussions.microsoft.com> wrote in message
news:70**********************************@microsof t.com...

In VS2003 using /clr meant that you could not use declspec import/export
to
import or export methods from a .dll so they could be used externally thus
requiring you to wrap a class using managed code and the /clr option with
a
class that did not use that option.

Is the same true for VS2005 or has that issue been resolved?

The situation is unchanged - you can't export a managed entry point, so if
you have managed code that you want to expose via DLL exports (which are
purely an unmanaged concept), you'll have to write an unmanaged wrapper over
your managed code and export that wrapper.

-cd

[Brandon Bray [MSFT]]

WXS wrote:

Thanks. I guess it makes sense, unfortunately we make heavy use of
declspec import/export as everything is a .dll so we would need to
create wrappers for every usage of managed code to avoid having to
compile the majority of code with the /clr option.

To be super clear, when compiling with /clr, everything that you could do in
your code before you can still do. The /clr option only enables you to do
more.

If you have a function F compiled with /clr, the Visual C++ compiler
produces two functions for F. One has the unmanaged calling convention and
one has the CLR calling convention. One of these functions actually does
work (i.e. represents the source code written for F), and the other function
thunks (a.k.a. p/invokes) to the other function. This enables any function
outside of a ref class, value class, or interface class to be exported with
dllexport.

Inside of ref classes, value classes, and interface classes, the compiler
only generates the CLR calling convention function.

There are numerous ways to control how all these features work. Reading
through the documentation is going to be your best help right now. For the
short term, I'd encourage just recompiling all your code with /clr to see
that it still works.

Hope that helps!

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/

[Brandon Bray [MSFT]]

WXS wrote:

Thanks. I guess it makes sense, unfortunately we make heavy use of
declspec import/export as everything is a .dll so we would need to
create wrappers for every usage of managed code to avoid having to
compile the majority of code with the /clr option.

To be super clear, when compiling with /clr, everything that you could do in
your code before you can still do. The /clr option only enables you to do
more.

If you have a function F compiled with /clr, the Visual C++ compiler
produces two functions for F. One has the unmanaged calling convention and
one has the CLR calling convention. One of these functions actually does
work (i.e. represents the source code written for F), and the other function
thunks (a.k.a. p/invokes) to the other function. This enables any function
outside of a ref class, value class, or interface class to be exported with
dllexport.

Inside of ref classes, value classes, and interface classes, the compiler
only generates the CLR calling convention function.

There are numerous ways to control how all these features work. Reading
through the documentation is going to be your best help right now. For the
short term, I'd encourage just recompiling all your code with /clr to see
that it still works.

Hope that helps!

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/