Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / July 2005

Tip: Looking for answers? Try searching our database.

/clr option for VC++ 2005

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
WXS - 06 Jul 2005 21:19 GMT
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] - 06 Jul 2005 22:46 GMT
> In VS2003 using /clr meant that you could not use declspec import/export
> to
[quoted text clipped - 4 lines]
>
> 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 - 08 Jul 2005 19:50 GMT
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.

> > In VS2003 using /clr meant that you could not use declspec import/export
> > to
[quoted text clipped - 11 lines]
>
> -cd
Brandon Bray [MSFT] - 08 Jul 2005 20:11 GMT
> 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!

Signature

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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.