As said in previous post, I worked to a replacement of OCWrappers and it is made.
How it works: there are three steps build:
- generate a XML API file, this is equivalent of CDL files but is easier to parse and populate. There is a visual tool that will scan from old OCWrappers with reflection and you will pick which methods are used. This API file make distinction between methods and properties.
- from this XML file are generated and updated C# and C++ projects with code. This is the most boring side, but also is where the power stands. The code generator makes patterns of code that are friendlier to debug. Also this part will make sure that the compiled code (mostly C++ side) will not include more than is needed.
- you have to rebuild the updated projects. In a typical workflow you will want to link to the C# project to see if all dependent classes. For now just the string type have to be fixed manually (because strings can be both wide strings and char* strings, two ways or repreenting Unicode and ANSI string encodings). Also, the C++ build is based on QMake (part of Qt SDK) for simplicity.
This design permit to improve all wrapping stack, is also a C# codebase and at the end makes a easier to work with both resulting code and with wrappers in themselves. As when the 6.5 OpenCascade issues will be found, the migration to new wrappers is possible as classes were written in a separate namespace and uses a different naming convention, so from gp_Pnt will get to gpPnt, and functions that return one number, will be likely automatically become properties which make easier for C# used eye.
The C++/C# projects permit to use different compilers (mostly different Visual Studio versions) for C++ side of wrapper/C# side, so makes sense in future to migrate to Visual Studio 2010 (when the C++ wrapper is still using VS 2008) so no binary compatibility issues will be involved.