For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings


Need to speed up your development?
Have a look at our:

Samples & Tools


Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Question about C# wrappers

Michael Bate's picture

I have written a few C# programs (VS2010) which call C++ native code DLLs, via DLLImport.

I gather that with OpenCascade I need to provide wrappers and am considering buying the wrapper package from OpenCascade SAS.

But I would like to understand what is involved.

Specifically, looking at the C# sample, the file OCCViewer.CPP appears to consist not of wrappers but of another class altogether (OCCViewer) which calls the OCC library. For instance, this includes the simple function:

void OCCViewer::RedrawView(void)
if (!myView.IsNull())

Redraw is defined in V3dViewer.hxx as:

Standard_EXPORT void Redraw() const;

V3dViewer.hxx is listed as an external dependency of the OCC project (which produces a C++/CLI DLL).

Standard_Export is defined in Standard_Macro.hxx as:

define Standard_EXPORT __declspec( dllexport )

"DllImport" never appears in this code.

What part if this is considered a "wrapper"?

Is there a discussion somewhere on how to create these wrappers?

I am aware of the difference between statically and dynamically loaded DLLs. DLLImport appears to generate a dynamically loaded reference, while the code above generates a statically loaded one. I can't find anything in my book about C# that addresses how to create a static DLL reference. Can someone point me to such a description?

Thanks in advance,
Michael Bate

Pawel's picture

Hello Michael,

some hints:

- there were some discussions in this forum about C# wrappers for OCCT so I suggest you maybe looked for these.

- it is possible to call unmanaged C++ from C++/CLI (Managed Extensions) and so there is no need to use the "DllImport" attribute (this is how the "shell" project works)

- I would recommend compiling OCC as unmanaged code (otherwise both the "OCC" and "shell" projects are C++/CLI - why?) - that way you can use further unmanaged DLLs through OCC if you want to.