Feature: dotnet bindings #146
Conversation
- Created CMakeLists.txt for building C# bindings with P/Invoke support. - Implemented Roofer.cs as a C# wrapper for the Roofer library, providing classes for LinearRing, Polygon, Mesh, and TriangulatedMesh. - Developed a C wrapper (roofer_wrapper.cpp and roofer_wrapper.h) to facilitate interaction between C# and the Roofer library, including configuration management and reconstruction functions. - Added methods for managing reconstruction configurations and retrieving mesh data. - Ensured proper memory management and disposal patterns in the C# wrapper.
compiled dll's are still included in git, to ease testing. Should be removed in future builds. TODO: figure out how to do automated cross platform building of the required binaries.
|
Great to read you had success in making this work! Since I am myself not familiar with C#, my initial preference would be to keep the C# bindings in a separate repository. Just to prevent the case where the bindings break due to some change in the C++ code. If I then release a new roofer version, it could ship with broken C# bindings, which is not nice. This would be easier to manage with a separate repo for the C# bindings, it could just keep using an older roofer version until the C# bindings are fixed. Regarding the errors. I am open to suggestions on how to improve this situation. What would be the best practice to get these errors nicely in C#, and what would need to be changed on the C++ side? And if there are any other issues that require some work on the C++ side please let me know. |
|
I'm perfectly fine with releasing .net as a separate stage. Longer term, we should solve that with unit/functional/integration tests as well, but there's probably some other trouble on the road as well. This would be needed for me as well, since native/non-native debugging works with Visual Studio, but it will become increasingly complex to do so cross-platform. Right now, I think my main strategy is to debug on Windows and rely on cloud builds to verify that the same things also work cross-platform. Note: NuGet (the package release system) is versioned, so if a version is broken, developers can fall back to another version. I will flag it as experimental for the coming times anyway. Cross-platform building is one of the things where I could really use some help/expertise. Is it very complex to set up a (sample) GitHub pipeline to compile Roofer, including the C#/cpp binding libraries, as artefacts for multiple platforms? Most common approach for NuGet is to release a platform-independent C#-only wrapper code, and release a separate native pre-compiled package for each platform (or combine them all if the resulting package size is compact) As for exceptions, Thanks! I'll dive back into the code and let you know. I think this is the most solvable problem, and I think I should be able to solve most of it on my side. |
2 participants
Note: This is not a mergeable request at this stage, but a request for comments.
This is a proof-of-concept build of .NET bindings for Roofer, based on the existing Python API bindings. I've successfully reconstructed a synthetic test set of points into a building, the bindings seem to work on both .net48 and recent dotnet core.
But the most crucial question at this stage is: Is having a dotnet library interesting for integration in the primary maintainers of Roofer, or should this be a separate project?
If so, these are my: Open topics that need resolving, and I could use some other eyes on this topic.
[ ] How to handle cross platform native builds (linux, osx, windows)
[ ] Creating a nuget workflow with native dependencies.
[ ] Translating roofer errors to C# (everything now becomes a generic "something went wrong in native code" error.