C DLL to C# (types exporting)

[A n g l e r]

Hello there.

I've got a DLL written in C convention. There're a few of enum types
that I would like to make available to C#. Is there any easy way of
doing this (exporting, etc.), or do I have to redefine all custom types
in C# (especially enumerations)? Normally, I go over these problems by
using wrappers from unmanaged to managed code and build DLL's with /CLR
option, but this time the DLL has to be developed in C convention.


Cheers,
Peter.

 

[Ben Voigt [C++ MVP]]

Hello there.

I've got a DLL written in C convention. There're a few of enum types that
I would like to make available to C#. Is there any easy way of doing this
(exporting, etc.), or do I have to redefine all custom types in C#
(especially enumerations)? Normally, I go over these problems by using
wrappers from unmanaged to managed code and build DLL's with /CLR option,
but this time the DLL has to be developed in C convention.

How about good old C-style reuse? Make your C source file look like so:

enum anenum {
#include "anenum.h"
}

Then you can have a C++/CLI wrapper project with an enum class compiled with
/clr that #includes the same header file.

 

[A n g l e r]

How about good old C-style reuse? Make your C source file look like

so:
enum anenum {
#include "anenum.h"
}

Would you elaborate a bit on this? I've never met the include keyword in
such a syntax.

Cheers,
Peter.

 

[Peter Duniho]

Would you elaborate a bit on this? I've never met the include keyword in
such a syntax.

The #include directive will cause the preprocessor to simply replace the
directive with the contents of whatever file it references. So if you
have a file that contains just the "guts" of the enumeration, you can
#include it from within the enum declaration itself.

Example:

file myheader.h:

enum anenum
{
#include "anenum.h"
}

file anenum.h:

Value1,
Value2,
Value3

Then when compiled, the compiler winds up seeing this:

enum anenum
{
Value1,
Value2,
Value3
}

How this addresses your original question is not clear to me. You seem to
be asking how you can effectively import enumerations declared in C, into
a C# program. While you could define the enumeration as suggested, I'm
not aware of any way to do the similar #include in C#, so having the
internal part of the enum declaration in a separate file doesn't seem to
help you.

Maybe Ben can elaborate on his suggestion, especially regarding how he
expects it to be used from the C# side.

Pete

 

[A n g l e r]

How this addresses your original question is not clear to me. You

seem
to be asking how you can effectively import enumerations declared in
C, into a C# program. While you could define the enumeration as
suggested, I'm not aware of any way to do the similar #include in
C#,
so having the internal part of the enum declaration in a separate
file
doesn't seem to help you.
Maybe Ben can elaborate on his suggestion, especially regarding how he
expects it to be used from the C# side.

Normally, you would give a go to a managed library compiled with /clr,
so managed C++ project code would be visible to C# (if attached to a C#
based project). The following example explains this a bit (I assume
#include is supported by a managed syntax as well - haven't tried yet).
What I'm wondering is whether I could avoid this and just use
include-like directive in C# or sth likewise so not to create a managed
wrapper just for sake of sharing enums ....

#ifdef _MANAGED

using namespace System;
using namespace System::Runtime::InteropServices;

public ref class MyClass1
{
private:
....

public:
typedef enum class SomethingClass: uchar { #include "anenum.h" };
};
#endif

 

[A n g l e r]

Right, I know how to walk around these restrictions. Create a header
file, let's say enums.h with the following example content:

enum Enumerator01: uint
{
member1 = 0x80000000,
member2 = 0x40000000,
member3 = 0x20000000,
// ... etc.
GMEEC_NOUGHT = 0x00000000
};


Now, this can be just included by a C++ project (#include "enums.h").
What concerns a C# project, just add to a project the file as an
existing item "Add->Existing Item", then click on the file in the
"Solution Explorer" and swap the "Build Action" property from "Content"
to "Compile".

Cheers,
Peter.

 

[A n g l e r]

Right, I know how to walk around these restrictions. Create a header
file, let's say enums.h with the following example content:

There are two or three more issues worth mentioning here (if anybody was
interested in this issue).

1. If enum type is based let's say on unsigned __int type, c/c++ project
should include definition of type "typedef unsigned __int8 byte" and a
file shared amongst c and c# would look like:
enum Enumerator02: byte
{
member1 = 0x80,
member2 = 0x40,
member3 = 0x20
// ... etc.
};

Then C# compiler is happy to recognize this type as well as c/c++ at the
same time.

2. Whilst enums.h is being included, VC copies this by default to C#
project folder. There are some bizarre problems then in order to open
this file from c# folder, but this can be walked around.

3. Original enum.h should be laced in a folder containing c/c++ project.
When compiling this, the "post-build event" from options should take
care of copying enum.h from its c/c++ directory to c# directory and
changing extension to enums.cs.

This seems to be pretty comfortable at the moment and good enough.
Cheers, P.

 

[Ben Voigt [C++ MVP]]

Normally, you would give a go to a managed library compiled with /clr, so
managed C++ project code would be visible to C# (if attached to a C# based
project). The following example explains this a bit (I assume #include is
supported by a managed syntax as well - haven't tried yet). What I'm
wondering is whether I could avoid this and just use include-like
directive in C# or sth likewise so not to create a managed wrapper just
for sake of sharing enums ....

That's basically what I intended for you to do, but...

#ifdef _MANAGED

using namespace System;
using namespace System::Runtime::InteropServices;

public ref class MyClass1
{
private:
....

public:
typedef enum class SomethingClass: uchar { #include "anenum.h" };

Preprocessor directives need to appear on their own line, you can't put
#include in the middle of a line.