DLL Development in C# - Exporting functions

  • Thread starter Thread starter Stijn
  • Start date Start date
S

Stijn

Hi there,

I have the following problem. At the moment I am creating an
application that interfaces with several hardware modules via USB.
Each of these devices has its own functionality and I want to make
this functionality available to programmers in a very generic way.
Therefore I came up with the following idea.

1) USB devices can have a small description. In this description i
will store the name of the DLL that covers the device its
functionality.

2) When the USB device is plugged in, the application will load the
DLL stored in the device. This will only be generic functions that
count for all devices.

3) These DLL's then provide some generic functions that enable
programmers to load the device specific functions from the DLL.

Im am sure this will work, I know how to do it in C, but my managers
want me to develop this in C#.NET. I read some articles on DLL's in C#
and I know how to write some basic DLL's in C#, but I couldn't find
the dynamics I need for this solution. Is it even possible in C# and
how can it be done?

Thank you in advance!!

Stijn
 
Stijn,

You won't be able to do this with C#. In .NET, you can not create
assemblies that export functions, as you can do in C.

If you want to do this, then you will have to create a C wrapper which
will subsequently make calls into a .NET managed assembly. At that point,
you can use C# to interface with the C code that is called.

Hope this helps.
 
Nicholas,

see inline ***

Willy.

Nicholas Paldino said:
Stijn,

You won't be able to do this with C#. In .NET, you can not create
assemblies that export functions, as you can do in C.
Click to expand...
Actually you can, using ILASM , but this is something you should never do :-).
Just consider following sample.


// unmexports.il
// Compile with : ilasm unmexports.il /dll
assembly extern mscorlib {}
..assembly UnmExports {}
..module UnmExports.dll
// This flag is important
..corflags 0x00000002
// This instructs the CLR to create a marshaling thunk for the unmanaged caller
..vtfixup [1] int32 fromunmanaged at VT_01
..data VT_01 = int32(0)
..method public static void foo()
{
..vtentry 1:1
..export [1] as foo
ldstr "Hello from managed world"
call void [mscorlib]System.Console::WriteLine(string)
ret
}


---------------------------------------------------------------
// File: Callmngd.cpp
// Call's a managed function through the managed assembly's export table
//#include <stdio.h>
#include <windows.h>
// compile using: cl Callmngd.cpp
typedef void (*FOOPROC)(void);

void main(void)
{
HINSTANCE hinstLib;
FOOPROC FooAddress;
bool res = false;
// Get a handle to the DLL module.
hinstLib = LoadLibrary("unmexports");
// If the handle is valid, try to get the function address.
if (hinstLib != 0)
{
FooAddress = (FOOPROC) GetProcAddress(hinstLib, "foo");
if (0 != FooAddress)
{
// Call managed function
FooAddress ();
}
// Free the DLL module.
res = FreeLibrary(hinstLib);
}
}


Willy.
 
Mattias,
Let's say I meant "IMO you should consider the alternatives before going down that road", but I agree, it may have it's uses.

The problem with this solution is that, currently (AFAIK), none of the high level languages (C#, VB.NET etc...) do expose the
managed methods as unmanaged exports, so your only option is to program in ILAsm or to round trip a piece of code written in a high
level language.
Round tripping is rather cumbersome, and, its not easy to write any reasonable sized application using ILAsm.

As first alternative there is MC++ which offers a perfect solution when one needs to mix unmanaged and managed (C++) code.
When you need to call managed methods from other unmanaged languages, and you don't mind to create an extra layer, you could write
a wrapper in MC++ and export the unmanaged functions that call the methods, or you could expose your managed classes as COM
interfaces to be consumed by COM clients.

Willy.
 
Willy,
Let's say I meant "IMO you should consider the alternatives before going down that road", but I agree, it may have it's uses.
Click to expand...

OK cool, then we agree :)



Mattias
 
Stijn,

You may want to look at Eric Gunnerson's article, "AppDomains and
Dynamic Loading":

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp05162002.asp

It's not as easy as the old LoadLibrary() and GetProcAddr(), and it may
only get you to the generic functions (an interface in .Net terms), but
you may be able to re-architect to access the specific functions within
this framework...

--
Steve Rosenberry
Sr. Partner

Electronic Solutions Company -- For the Home of Integration
http://ElectronicSolutionsCo.com

(610) 670-1710
 
Back
Top