Cyclone dds for C#?

[knutur94]

Hi

In your Roadmap you say you want a C# API. Is that a thing that's being worked on, or is it still way off in the future?

[photex]

I'd also love to find out that this is being worked on somewhere. Or if there is a task list that's just waiting on some contributors to step up.

[eboasson]

A colleague of mine did start on it at some point, but the priorities and availability of time shifted. The effort has basically been abandoned after solving the problems. It'd be great if some contributor would be interested in taking over the effort, C# is quite a rather nice language and also much more portable these days than it used to be.

[photex]

@eboasson Is the existing work someplace public? I don't have a mandate or dedicated chunk of time yet, but I'd like to investigate and make an estimate.

[noxpardalis]

@photex I had been working on it internally, but the work wasn’t far enough along to be useful to make public. That said, it might be helpful to share some details about where it was:

• I created an FFI module that wraps a bunch of functions from the CycloneDDS shared library. This essentially involved wrapping the functions like so:

  [DllImport("libddsc", CallingConvention = CallingConvention.Cdecl)]
  

  along with a few type mappings for errors and related constructs.

• I implemented wrappers for the core types: Domain, Participant, Reader<T>, Writer<T>, Topic<T>, etc. These were designed to work with the using statement to support scope-based resource deallocation.

• Started work on the sertype/serdata wrappers.

• I loosely based the structure on the set of interfaces defined in the WIP OMG C# spec: https://www.omg.org/spec/DDS-CSHARP

[!note] I tried looking for the WIP spec again cause the URL was 404ing and it seems to have been scrubbed from the OMG website (at least I was unable to locate it again on the spec search index)

The next steps were going to be:

• Building a CDR parser
• Performing type introspection on the user-provided types to do dynamic deserialization from the data received over the wire.
• Finalizing the sertype/serdata wrappers
• Completing the rest of the API wrapping (e.g., waitsets, full QoS support, etc.)
• Adding async support and designing a LINQ-compatible API

In my view, these last steps are where the real hard work lies.

For now, the best examples for building a language binding are the C++ binding (for statically compiled languages) and the Python binding (for dynamic languages).

That said, I was never the most experienced with C#, and so having a community-maintained C# API, driven by people who know the language inside and out would be awesome! I'm happy to have further discussions on this issue on GitHub otherwise you can also feel free to hop onto the CycloneDDS Discord channel: https://discord.gg/4QQvWZrFKF.