feat(ffi): initial C# bindings (connector only)

[irvingoujAtDevolution]

Created skeleton for FFI.

Connector module is working now. Please see ffi\dotnet\Devolutions.IronRdp.ConnectExample

Note: this is a draft, we'll need to discuss more about

1. how would we like to expose rustls.
2. how would we like to handle generics like framed and static channels.
3. should we expose async interface? or just stick with the sync one?

There are some imperfections/todo/fixme for now, my apologies.

[github-actions]

Coverage Report 🤖 ⚙️

Past:
Total lines: 29575
Covered lines: 17244 (58.31%)

New:
Total lines: 29575
Covered lines: 17244 (58.31%)

Diff: +0.00%

[this comment will be updated automatically]

[irvingoujAtDevolution]

formatter seems not working anymore, it does not tell you where the format is wrong, neither could cargo +stable fmt --all fix it.

update: somehow formatter require me to fix a place I never edited, it is inside crates/ironrdp-testsuite-core/tests/pcb.rs

[CBenoit]

• how would we like to expose rustls.

We don’t expose rustls, we’ll use SslStream in C#.
The API we expose should be sans-IO and we only push and pull bytes from a state machine. This means that as a rule of thumb, we don’t perform any I/O in the ffi crate (not even using TcpStream).

https://sans-io.readthedocs.io/how-to-sans-io.html#why-write-i-o-free-protocol-implementations

IronRDP is already largely following this philosophy (and IronVNC too). We do expose higher level helpers to simplify things in upper layers, but this is not part of the "core crates".

• how would we like to handle generics like framed and static channels.

Let’s not expose the API for static channels like we do in Rust. I think we can safely hardcode the supported channels like this. We’re not going to implement static channels in C# either, so there is no need to care too deeply about genericity here.

As for "Framed", it’s not supposed to be exposed. This is a higher level helper for Rust code.

• should we expose async interface? or just stick with the sync one?

We stick to the "core" API, which is "sans-IO" and thus do not require choosing between async or not.

However, we should provide an higher level API which may be async.
The additional handwritten classes or addons should live in a src/ folder like in Picky: https://github.com/Devolutions/picky-rs/tree/master/ffi/dotnet/Devolutions.Picky/src

However, let’s stick to the standard C# library in the higher level helpers. I don’t think we need much more than that and it will save us maintenance time. If a fancy dependency is required, let’s handle that downstream (in RDM).

[CBenoit]

nitpick: Avoid to update the Cargo.lock more than necessary. We use dependabot to update it piece by piece in a controlled way.

[irvingoujAtDevolution]

updated!

[CBenoit]

Can you also add a .gitattributes file like we have in Picky?
https://github.com/Devolutions/picky-rs/blob/master/.gitattributes

[CBenoit]

LGTM! Thank you!!