使用x86 / x64 C API的C＃AnyCPU库-打包结构，调用和回调

Question

I`m searching and trying all sort of solutions for like two weeks now to make the following possible: port 32-bit libraries and C++/.NET wrappers to 64-bit (for C++) and AnyCpu (for .NET).

There is:

• a C++ library which exposes a C-style interface further referred as "The Brain" (this is how we all call it)
• a second C++ library (DDC) which uses The Base is more like a wrapper for it, in the way that it packs a very nice interface
• a .NET library (DDN) which uses The Base and acts like a wrapper for C# and VB
• a JAVA library (DDJ) [ not important, we have separate development to handle this ]
• a PYTHON library (DDP) [ not important neither ]

The libraries are huge, in the way that there are thousands of structures and functions (interfacing with databases and with some various Ethernet devices). There is lots of functionality which I don`t even know why is kept in the code, but requirements are requirements and must be obeyed...

The entire driver and database connector had only 32-bit configurations. There is no relevant documentation on anything inside and a lot of code had to be modified (not rewritten or refactored, but modified).

All the structures are aligned on 4 bytes, marshalling between .net and C API works ok on 32-bit.

The new requirement is to create AnyCPU .NET configuration which to use the 64-bit respectively 32-bit Base according to the system the VB/C# application runs on.

So far so good - DDC works nice with The Base. but when it comes to DDN - there is a whole lot of s### happening: the structures to be marshalled and unmarshalled with The Base have a pack on 4 bytes... Therefore, the alignment of the Base structures has been switched to 4 bytes for both 32-bit and 64-bit (was 4 respectively 8 bytes).

My initial plan was with alignment on 4 and 8 bytes for 32-but respectively 64-bit configurations, but there is a lot of work to do in the .NET API interfacing with the Base C wrapper... the calls and callbacks are separated within different namespaces, each including the respective library, but the structures are a pain...

The second plan was to align everything with either 4 or 8 but there are a lot of warnings regarding the packing of structures and unary operators... Besides those warnings, nothing works nice anymore. Heap corruptions, shutdown crashes etc..

A third solution would be to switch back to solution 1 and create structures with appropriate packs on both namespaces (the namespace interacting with 32-bit Base library and the namespace interacting with the 64-bit Base library)

I would greatly appreciate any feedback. Please do not hesitate to ask for more information if anything is unclear.

Thank you all!

Answer 1

In my experience is a very bad idea passing pointers from/to unmanaged code to managed code. If you use callbacks the final result can be worst than expected. You must remember that .NET defragments the memory so the phisical addresses of the pointers may vary (so you can imagine the things that may happen).

---

Solution A: Make it simple, if you want to mix unmanaged with managed do it with C++ managed using unmanaged C (so, no any CPU solution). Oracle Data Access is an example of this solution.

---

Solution B: Split the solution in two projects, one managed and one unmanaged. Objects shared between layers must be in the unmanaged side. You must forget about callbacks between unmanaged and managed projects. This solution is used in SQLite drivers for .NET.