C# support

[joylital]

• .NET Standard wrapper
• Functional tests
• Unit tests
• CI Automation
• NuGet Packaging
• SDK Packaging

C# support

Target .NET Frameworks

• .NET Framework (desktop apps)
• .NET Core (Windows and Linux)

Target UI Framewoks

• WPF
• WinForms

[Brent-A]

The current proposal is to implement C# support as a managed .NET Standard wrapper that uses P/Invoke to interface with k4a.dll and k4arecord.dll. We can then have additional framework specific assemblies for WPF/WinForms/etc. that reference and extend the core functionality.

We need to avoid changes in the public headers and APIs that might impact the managed marshalling, since we don't have a good method to validate correctness for all of the API usages.

We need build system support to ensure that the C# is compiled and tested as part of the normal CI.

[Brent-A]

An implementation is underway in feature/csharp

[Brent-A]

Currently the wrapper is "feature complete" for the basic live API, but not yet implemented for recording or playback. There is some functional and unit test coverage, but more to come.

For the C# API design the biggest point of consideration is access to the underlying raw memory and ensuring managed code safety in the application. We can expose a direct IntPtr referencing the buffer, and expose APIs to copy data in/out of IntPtrs, however this is not a safe operation in managed code and requires that the caller be very careful with the lifetime of the managed objects to avoid memory corruption.

The current design goal is to provide a safe by default implementation which allows the caller to stream, process, and render data in a reasonably performant manner, but still provide access to users who are willing to use unsafe blocks to access the data directly when needed.

[vpenades]

@Brent-A I have some thoughts for the C# wrapper:

I've noticed the body tracking SDK uses some structures of the Kinect4A DK, in particular it uses k4a_result_t, k4a_calibration_t, k4a_wait_result_t, k4a_capture_t , and might use others too...

I don't know if it's possible, but it could be interesting if the new Body tracker could be used offline, even without a device plugged, for which it could be interesting to use the body tracker without dragging the whole Microsoft.Azure.Kinect.Sensor.... so I was thinking if it could be possible to split the project into two assemblies.... something that would only containt the core, exchangeable types (so it could be used separately) and another one for the actual API.

About accessing IntPtr* .... its something we do use in our current implementation of Kinect2 for performance reasons, if such an API is considered, it could be nice if the exposed API uses ReadOnlySpan instead of IntPtr*

[DerekMa-WP]

The bulk of the C# support is in develop now and we are mostly working on cleanup, bugs, and documentation. Closing this issue out in favor of individual issues for the remaining work.

[Sn34k]

By Chance is this SDK for the V2 Kinect Sensor!?

[DerekMa-WP]

This SDK only supports the Azure Kinect DK. It does not support the Kinect for Windows v2.

[hcghanta]

When can I expect the C# wrapper for Body Tracking SDK?

[dhgokul]

@MsDerekMa Any updates on C# wrapper for Body Tracking ?

[dhgokul]

Guys check it below link,it may be useful
https://ivatilca.wordpress.com/2019/08/22/first-azure-kinect-app-c-api-vs-c-k4a-nuget-package/ - Explain both how to use C API and C# API

[DerekMa-WP]

@dhgokul as noted in #689, we don't have the the C# wrapper for Body Tracking planned. We are tracking the request on the feedback site, https://feedback.azure.com/forums/920053-azure-kinect-dk/suggestions/38661742-bodytracking-c-wrapper, to help us understand interest levels.