[CSharp API] Add and init modules.csharp_api project, provide methods for using the CSharp API

[guojin-yan]

The OpenVINO C # API project is developed based on the OpenVINO official interface C API, and combined with the OpenVINO C++API features, it reconstructs the core, model, sensor, InferRequest and other class objects in C #, implements the C # API and calls OpenVINO in C #.

[redradist]

Please add MacOS build script as well since .NET5, .NET6 and later are all cross-platforms

[guojin-yan]

Please add MacOS build script as well since .NET5, .NET6 and later are all cross-platforms

Hello, thank you very much for your valuable feedback on my CSharp API. I will also make modifications and resubmit it in the near future. However, due to my limited programming skills, there are certain issues with the content of the project I am currently submitting. I will continue to improve my programming skills and further improve the project in the future.
I have a question during the modification process. As you can see, my previous work mainly focused on Windows and Linux environments, and did not involve the MacOS system. With your suggestion, I am preparing to develop a build case on the MacOS system. However, before conducting this exploration, I have a few questions to confirm:
Firstly, the MacOS system testing environment requires whether the test needs to be run on M1+MacOS chips or on InteI CPU+MacOS environments. As InteI CPU+MacOS devices cannot be purchased in China at present, I would like to confirm this issue.
Secondly, if it is necessary to develop a MacOS case, I can install a MacOS environment on my computer for testing. What is the specific version of MacOS? May I ask if there are any test cases of OpenVINO in the MacOS environment, C++or Python versions?
Thank you again for your valuable feedback on my CSharp API and look forward to your reply!

[redradist]

@guojin-yan Why did you close PR ?

[guojin-yan]

@guojin-yan Why did you close PR ?

I am very sorry, but I was not familiar with the process of submitting a PR before because I haven't received a response for so many days. I thought there was a problem with the submitted project, so I closed this PR. Now I will reopen this PR and submit the updates I have made in the past few days.

[redradist]

@ilya-lavrenov @ilyachur @iefode @nkogteva Could you also look at this one ?

[guojin-yan]

  @redradist Hello, during this period, I have made further updates to the previous code, improved some interface functions based on the current C API, implemented some indefinite parameter interfaces, and some complex interfaces. At the same time, unit testing has been improved. In this submission, unit testing projects have been added, and over 98% of the interfaces have been tested.
  In the latest released version, support for the MacOS system has also been achieved. As of now, it has successfully supported Windows, Linux, and MacOS systems, and related use cases will be released in the future. At the same time, I also submitted a request to extend the C API on the official OpenVINO platform, as currently the C API interface does not fully support all interfaces.
  Thank you very much for your guidance on this project. Your valuable feedback has been of great help to my project. As I am only a beginner, there is still much room for improvement in C # programming. I hope to receive guidance from all the teachers.

[redradist]

@ilya-lavrenov @ilyachur @iefode @nkogteva Could you also look at this one again ?

[redradist]

@ilya-lavrenov Why did you close this PR ? Isn't it needed for OpenVINO to have more programming languages support ?

[ilya-lavrenov]

@ilya-lavrenov Why did you close this PR ? Isn't it needed for OpenVINO to have more programming languages support ?

The project can live its life, we don't have to merge everything related to OpenVINO to contrib repo.

Contrib repo is a sandbox repo, where projects related to OpenVINO can initially live. When the project became more mature, it can be forked to a dedicated repo. Example is OpenVINO Tokenizers

All OpenVINO ecosystem projects are listed here https://github.com/openvinotoolkit/awesome-openvino

[redradist]

@ilya-lavrenov I thought that https://github.com/openvinotoolkit as organization consolidate all ecosystem under its umbrella, otherwise it is hard for user to find C# bindings ...

How general user will find rust_api or csharp_api if they are not mentioned in either OpenVINO Docs nor located under https://github.com/openvinotoolkit organization umbrella ?

[ilya-lavrenov]

I thought that https://github.com/openvinotoolkit

Maintaining all these projects costs big effort on both infra and development team.
We don't have such capacity

How general user will find rust_api or csharp_api

Easy with google

CC @p-wysocki @mlukasze who are working on GFI and consolidating projects in OpenVINO ecosystem. Maybe we can better highlight it in our docs

[mlukasze]

Please also to our list of project federated with OpenVINO
https://github.com/openvinotoolkit/awesome-openvino

[redradist]

@ilya-lavrenov

I thought that https://github.com/openvinotoolkit

Maintaining all these projects costs big effort on both infra and development team. We don't have such capacity

How general user will find rust_api or csharp_api

Easy with google

CC @p-wysocki @mlukasze who are working on GFI and consolidating projects in OpenVINO ecosystem. Maybe we can better highlight it in our docs

I think you could do it much easier ...

Here is how I would did it:

1. Consolidate all <language>_api in openvino or as temporary in openvino_contrib (while api is not yet stabialized)
2. Choose maintainers for each subprojects, for example userA responsible for everything that goes in folder rust_api, userB responsible for everything in csharp_api (both users userA and userB could work at Intel or be external contributors that was chosen to be maintainer)
3. Trigger each subproject CI only in case PR contains changes from csharp_api subfolder (just like it was done for nvidia_plugin)
   and next ... Enjoy collaboration and contribution :)

It would bring the following benifits:

1. Improved API synchronization
2. Single place of api and community best plugins
3. Decentralized maintenance (each subproject has its own responsible maintainer), if some maintainer will decide stop be maintainer, OpenVINO tam could choose new one or take it under its maintenance umbrella

Not doing that OpenVINO loosing battle between AI runtimes as for me

[ilya-lavrenov]

I think you could do it much easier ...

It's not so easy as it seems.
For example, Rust API is still based on OpenVINO API 1.0, which is already removed in OpenVINO master. Who would migrate Rust API to OpenVINO 2.0? We don't have such capacity in core team.

All code requires maintenance.

[redradist]

@ilya-lavrenov

I think you could do it much easier ...
Who would migrate Rust API to OpenVINO 2.0? We don't have such capacity in core team.

All code requires maintenance.

Choose maintainer not from core team, but from developer which contributed the most.
In case of rust_api it could be @abrown, in case of chasrp_api it could be @guojin-yan.

As for me it is that simple !

[ilya-lavrenov]

As for me it is that simple !

It's quite naive to assume that external contributors can respond within required time slot to perform changes in their components. Such projects are implemented in spare time, which can be absent at the moments when it's really needed.

[redradist]

As for me it is that simple !

It's quite naive to assume that external contributors can respond within required time slot to perform changes in their components. Such projects are implemented in spare time, which can be absent at the moments when it's really needed.

Some of them already doing pretty good job like @guojin-yan