Refacto C# interface

[Thiago-NovaesB]

In this Pull Request, I present a proposal for refactoring the C# interface.

Positive points:

1. Separates classes and enums into folders and files, making the code more readable and maintainable.
2. Renames methods and properties to follow C# convention (e.g starting with uppercase letters and not abbreviating words)
3. Annotations added to methods and properties.
4. Use of records instead of classes when appropriate.
5. Addition of mipcall, lpcall, and qpcall.
6. Suppression of call (depressed).
7. The interface is now a project, not just a file. Therefore, we can write cleaner tests.

Negative points:

1. It is not compatible with the previous version.
2. We need to rewrite the NuGet publication to publish the project.

If you think it's a good modification, I can help with NuGet. Or with another refactoring proposal.

Generally, if you're looking to make changes or tests to the C# interface, I'm open to helping.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.06%. Comparing base (710aaa3) to head (4902014).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2714      +/-   ##
==========================================
- Coverage   81.06%   81.06%   -0.01%     
==========================================
  Files         347      347              
  Lines       85219    85219              
==========================================
- Hits        69085    69083       -2     
- Misses      16134    16136       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jajhall]

I can well believe that the C# API would benefit from refactoring, as I think it just grew from a simple proof-of-concept wrapper around the C API, and we lack the C# expertise to rework it ourselves.

However, breaking the old C# API between major versions is unwelcome, and @galabovaa will have to consider the implications for the Nuget build.

We only use master for releases, with development pushes being made to latest.

[Thiago-NovaesB]

I see. If you prefer the new code organization but don't want to break compatibility, I can rename the items as they were.

[darrylmelander]

I have a few thoughts about this.

At first glance it looks like it does indeed break compatibility with the existing C# interface (I haven't had time to do more than browse the changes so far). Personally I'm not a big fan of the existing C# interface, and I could easily update my code, but breaking the interface for others is a big deal. Perhaps there's a sensible way to support both the old and new? I'll have to think through this.

Second, if we're going to break compatibility than perhaps this change doesn't go far enough! If we do this (and this is a big if) then I think there is more work to do before it should be released. Again, all I've done is glance at the changes so maybe I'm wrong, but my first impression is that it still has the feel of a translation from C, not a native C# interface. We don't want to break compatibility now, then break compatibility again in the future when we see more that ought to change.

Third, absolutely DO NOT target net9.0! It should target netstandard2.0 instead. I can't emphasize this enough! If you target net9 then it will only work with net9 and later. If, on the other hand, you target netstandard2 then you can use it with just about any reasonable version of .NET (including net9) and .NET framework. Don't make targeting decisions for users unless you absolutely have to.

I wish I had time to spend on this. I really do.

[galabovaa]

Thank you @darrylmelander and @Thiago-NovaesB

It is probably best to leave this for a later stage, when I've got the time to properly test compatibility and learn about native C#.