Repository navigation
C# api #18
Description
Activity
I'd really like to see a C#/.net wrapper. Shouldn't be too hard to p/invoke into the C++ API.
Reacted by Dave Friedel, Joannes Vermorel, Brans, Nauman Mustafa, Heath Hopkins, Etienne Tremblay, Mikey, Theodor Dimache, curimit, JimSEOW and 40 moreReacted by Thomas Guenther, veyvin, Robert N., Halid Cisse and Przemysław ZapaśnikPerhaps CppSharp could be of use? As opposed to SWIG?
Reacted by JimSEOW, Ahmet and Robert N.👍
This is something the core TensorFlow team is unlikely to tackle in the near future, so if you want to contribute it, please go ahead! I would recommend circulating a proposed implementation on the discuss mailing list early on, so that a consensus about where such API might live (in repo / off repo / in 'contrib' directory) can be reached ahead of time.
FYI, @zaphar has just contributed initial C# rules to Bazel. These rules are currently in an early state and currently only support Mono, but the plan is to add Microsoft .NET support once Bazel supports Windows. If anyone is interested in helping with improving Bazel's C# rules, contributions are definitely welcome. :)
Just a general +1 from me!
@davidzchen - I am not familiar with Bazel but assuming the that the idea behind you mentioning it being extended to run on Windows, along with the new C# rules, would be to allow us to build this repo on Windows, including the code for the potential .NET (mono) interop library?Could an alternative approach be to just build and distribute the native tensorflow libs (dll's) on NuGet - and then in a completely seperate repo, create this.NET interop. This seperate repo can be built using MSBUILD or something so would eliminate Bazel as a blocker?
Reacted by Nauman Mustafa and Mikey@dazinator Correct. I am not sure what the TensorFlow team has decided about where support for additional language should live (as @vincentvanhoucke mentioned, in the
tensorflowrepo, in separate repos, or in acontribdirectory). In the meantime, I'm sure it would be fine for somebody to pick this up, circulate a proposal, and implement C# support built using msbuild. We can add BUILD files later for users who would want to use Bazel instead of msbuild.I just wanted to put that out there in case somebody is interested in helping out with Bazel's C# rules. :)
The problem is not to invoke C++ code, but to translate the Python part of TensorFlow to either C# or C++. It has about 60K lines of code. That's where TensorFlow "magic" resides on...
I'm currently working on porting TensorFlow to Node.js, and we got stuck on this. Maintaining a synced version of some thousand lines of code will get out of control as soon as something changes in the Master. The way I see it working, is to translate the Python part of TensorFlow to C++.
If you guys are willing to help, please join us at slack: https://github.com/node-tensorflow/node-tensorflow
Reacted by GSPP@ivanseidel - I think one solution for the python code from a .NET perspective, would be to use IronPython - which allows you to:
- call your Python .py from within .NET
- run it
- get a result back into your .NET app from the Python code.
So i'd assume that for a C# implementation, we'd try and keep all the original python code as is (as much as possible) to save translating 60k lines (and keeping them in sync)
Saying that, this is a completely pie in the sky idea and I really haven't looked at any specifics yet! :)
Reacted by Mikey, Sammy Guergachi, Vladimir Akopyan and Nathan@dazinator That is a way out, but then, you cannot "writte" code from within C# context, you will be limited to writting TensorFlow code in
.pyand calling it from other languages...The Idea is to have all the tools available native in the language. Of course this is a working "work-around", but if you need a dynamic TF code, you will get somewhere limited by it =/
But, translating all those lines of codes from Python to C++, wouldn't need to be "in sync" anymore. Just the callers, but not the implementation code... It takes an effort, but a single effort, once, to make things the right way =)
@ivanseidel - I understand.
.NET also has good native interop, so porting this python code to C++ version could be good for both .NET and NodeJS
My comment around the "sync" was really about - if google decide to continue to evolve their python code, we'd have to continue to keep the c++ code base in line with that.. It would essentially be having to maintain there implementation as a fork - but I do understand the benefits :)
Reacted by Nauman Mustafa and Johann DirryYep, you are right...
As I see, keeping a fork for it is required, be it a Node.js fork for the Python code, or C#, or even Java. But if there is a fork for C++, all can use it in favor.. C++ is universal in this case, while no other language can support all others as much as C++...
In any case, if you feel engaged to it and would like to help, join us at slack (link: https://tensor-flow-talk-invite.herokuapp.com/). And good luck with it :)
As I think we have mentioned elsewhere, there is a lot of code in python that we do hope to move into the core C implementation (shape inference, gradients, etc), so that the language bindings only have to be thin, idiomatic wrappers around the core functionality. But as you know, it is quite a bit of work to do this, and we already have some 100+ open issues to prioritize against too, so please be patient with us.
88 remaining items
- added 7 commits that reference this issue
on Apr 9, 2025 - added 5 commits that reference this issue
on Jul 28, 2025 - added a commit that references this issue
on Nov 26, 2025
C# is very popular and expressive language with a large community of pro developers.