Trying to better understand dlls....

[sam]

I'm trying to better understand the relationship between unmanaged dlls
and accessing them from a managed language such as vb.net....

1-As I understand it, a DLL created in C++ as a win32 dll can be
accessed via a managed language as long as you export the functions and
use declare-type statements in the vb.net code and marshall the
passed/returned variables.

2-A DLL created in C++ as a MFC DLL seems to be similiar in those regards.

3-A DLL created in C++ as a CLR DLL doesn't need the functions
explicitly exported, and a managed language can access the functions in
the DLL without having to deal with Declare statements. Marshalling may
be required depending on the variables passed/returned.

Is this an accurate assessment?

[Patrice]

I would say :

- either you created a .NET dll. In this case by design, the DLL contains
the needed metadata so that it can be consumed by any other .NET application
(within CLS compliance)

- for any other kind of technology (exported functions or com classes) you
(or a tool) needs to create the information needed to access this outside
world (for com classes the DLL includes some metadata that a tool can be
used, function exported "à la declare" doesn't have any metadata).

Try :
http://msdn2.microsoft.com/en-us/library/sd10k43k.aspx
for details.

---
Patrice
"sam" <sp*******@gtnincs.coma écrit dans le message de news:
ek**************@TK2MSFTNGP04.phx.gbl...

I'm trying to better understand the relationship between unmanaged dlls
and accessing them from a managed language such as vb.net....

1-As I understand it, a DLL created in C++ as a win32 dll can be accessed
via a managed language as long as you export the functions and use
declare-type statements in the vb.net code and marshall the
passed/returned variables.

2-A DLL created in C++ as a MFC DLL seems to be similiar in those regards.

3-A DLL created in C++ as a CLR DLL doesn't need the functions explicitly
exported, and a managed language can access the functions in the DLL
without having to deal with Declare statements. Marshalling may be
required depending on the variables passed/returned.

Is this an accurate assessment?

[sam]

Patrice wrote:

I would say :

- either you created a .NET dll. In this case by design, the DLL contains
the needed metadata so that it can be consumed by any other .NET application
(within CLS compliance)

So Patrice, using the terminology I was using (based upon the default
projects in visual studio, would you say that a .NET DLL (as you put it)
would a a Visual Studio CLR DLL?

[Patrice]

CLR is the Common Language Runtime. Visual Studio is just a development
tool.

So don't talk about Visual Studio here. You could as well use Notepad or any
other third party tool and still compile your code to obtain the same DLL.

Talking about a CLR DLL is IMO ambiguous as it could be thought of one DLL
that provide some of the CLR capabilities.

My personal preference is to say a .NET DLL (that is a DLL that is created
using the .NET Platform and intended to be primilarly consumed on the .NET
platform).

You use visual Studio to create .NET DLL or .NET applications.

--
Patrice

"sam" <sp*******@gtnincs.coma écrit dans le message de news:
Om**************@TK2MSFTNGP06.phx.gbl...

Patrice wrote:

>I would say :

- either you created a .NET dll. In this case by design, the DLL contains
the needed metadata so that it can be consumed by any other .NET
application (within CLS compliance)

So Patrice, using the terminology I was using (based upon the default
projects in visual studio, would you say that a .NET DLL (as you put it)
would a a Visual Studio CLR DLL?