I am a C# .NET programmer and am learning Python. I have downloaded IronPython, and know that it can call into .NET libraries.
I'm wondering whether there is a way to do the reverse, that is to call into some existing "classic" Python libraries in my C# code, maybe using .NET Interop.
I'd like to be able to access functions in libraries such as pygame.
Ironpython 2.0 is CPython 2.5 compatible, so pure Python that uses <=2.5 APIs should work fine under Ironpython. I believe Ironpython code can then be compiled into a DLL.
For C-extensions like Pygame, you might want to take a look at Ironclad. It's a project to allow for C-extensions to be used within Ironpython. This may also give you the native code bridge you're looking for.
You can use Python for .Net, which allows you to 'use CLR services and continue to use existing Python code and C-based extensions while maintaining native execution speeds for Python code.'
Further, 'A key goal for this project has been that Python for .NET should "work just the way you'd expect in Python", except for cases that are .NET specific (in which case the goal is to work "just the way you'd expect in C#"). In addition, with the IronPython project gaining traction, it is my goal that code written for IronPython run without modification under Python for .NET.'
Hope this helps
Related
I'm learning about PInvoke to use a C++ library (with C-Style interface) in C#. After reading the documentation and searching Google/StackOverflow for additional information I was wondering about binary compatibility of the native library and .Net. I think I read something somewhere a while ago, but I couldn't find it anymore. And I could not find anything else on this.
When I compile a C/C++ to use in .Net, do I need to use certain configurations like compiler flags to make it compatible for PInvoke? Can I use native libraries made with different compilers in one .Net project, provided these libraries don't depend on each other?
I there anything else I need to know about C/C++ compilation for .Net PInvoke?
I would like to use GCC and CLang with CMake projects to create the native libraries.
P/Invoke has a lot of adaptation capabilities. Also P/Invoke is cross platform (with .NET Core).
However, it's not binary compatible with C/C++, but if a piece of C/C++ code can be used by P/Invoke, it's not dependent on the C/C++ compiler (MSVC or other), or said in another way, it will not be able to use any C++ construct, but it will see all C++ compilers as equal citizens
I have a rather large legacy nmake (Win32) project that creates a static library from native C++ code. I need to use this library in a C#/.Net application. In the past after much effort I had been successful at wrapping the static library in a managed C++ library, which I am then able to reference in a C#/.Net application. However, after receiving updates from the developers of the nmake project, and having gone through an many upgrades on my own build machine in the meantime, it is no longer working.
I am however able to import the cpp and header files of the nmake project and build it to a Win32 static library in VS 2010, by setting all of the preprocessor constants in the build properties. I set the build configuration type to DLL, and then try to add a reference to the Win32 output in my C#/.Net application hoping to use P/Invoke down the road, and it fails with a message "A reference to MyLibrary could not be added."
Is there a way to build the Win32 library so that it can be referenced by the C#/.Net project and so that I can use P/Invoke?
Is there a way to build the Win32 library so that it can be referenced by the C#/.Net project and so that I can use P/Invoke?
If you want to directly reference the library, you'll need to build a C++/CLI project using your library, and make managed wrappers.
If you want to use P/Invoke (which is a separate concept), you can make exports with a C API, and call those directly via P/Invoke.
The two approaches are both valid, but completely different in terms of implementation (C++/CLI vs. C API wrappers) on the native side, as well as used differently (directly referenced for C++/CLI vs. P/Invoke via [DllImport]).
You can use SWIG to generate wrappers for your code. SWIG is a very powerful tool and worth taking the time learn. It creates wrappers for a number of languages including Python, C#, and Java so if you get it working with one language it is fairly easy to use in other languages as well. It will generate all the wrapper code for you, although you will probably need to do some work with type. You use swig to create a special DLL that SWIG generates code for and then used supplied C# code to access the DLL without needing to deal with managed C++ assemblies which can be a nightmare to deal with.
http://www.swig.org/Doc2.0/SWIGDocumentation.html
Edit: my explanation may not be that clear and the docs are pretty overwhelming, take a look at the "What is swig?" section here to get started:
http://www.swig.org/Doc2.0/SWIGDocumentation.html#Introduction_nn2
Question ago (Reseting generator object in Python) I was recommended to use itertools.tee. Actually I'm using IronPython, in the library we can see many usage of this feature, but there is no implementation (in *.py). That is why I'm confusing how to include this package to my c# project?
itertools is a built-in module. In IronPython the majority of the built-in modules live in IronPython.Modules.dll. You should be able to just add a reference to this DLL and it should get deployed w/ your app by VS. IronPython should then pick it up and it should be availble from there.
I have a class library written in C#, and I want to call it from a legacy native C++ application. The host application is truly native, compiled on Windows and Linux, and it’s a console application. So how can I make it call the C# class library, assuming using Microsoft .NET on Windows, and Mono on Linux?
I have looked at SWIG and wrapping with COM interfaces on Windows, but is there a standard recognized solution that works cross platform? I.e., that is generic, works with both Microsoft .NET and Mono. A write-once-use-everywhere implementation.
Solutions should expose the full class interfaces from the C# domain to the C++ domain.
Similar questions focus only on the Windows solutions, for example -
Call C# methods from C++ without using COM
If you want to do this cross platform, I would recommend going with a 100% Mono approach.
Mono has a clean Embedding API which works on Linux and Windows.
With .NET 5.0 (the successor of .NET Core) this is now possible to call C# from C++ in a cross-platform way without using Mono. Please see the solution explained in this GitHub issue using DNNE to generate a shared library and GCHandles to access C# objects.
With this you get a shared library that can be used from C or C++. Note that this will give a C-like API (no objects, like when using extern C in C++), in the future there may be tools like SWIG for C++ to overcome this limitation.
Two Questions:
Is there any way to write cross platform programs on Microsoft Visual Studio?
If there isn't then could I write a C# application on VS2008 and recompile it with MonoDevelop and have it work?
1 - I dont' think so. Not without something like Mono.
2 - Yes you can, but Mono doesn't cover all the framework - they are working on it.
The best thing to do is check with the Mono Migration Analyzer. The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have on Mono - http://mono-project.com/MoMA.
I have found most of my .NET 2.0 applications can be converted, but you may need some tweaks.
You can always use C++ and QT. Soon QT will be released on LGPL license (from version 4.5) that will give some more freedom.
The only limit of using free QT license is that you don't get integration with VS. However this can be handled by using eg. CMake (which will generate VS solution files).
Yes, Write your code, compile and run on another platform using Mono. When you compile you generate IL, which Mono can use. Note: Some functions aren't available on Mono. Delphi Prism, is an add on for Visual Studio which allows you to code to Linux and Mac from VS albeit in the object Pascal language though.
Yes, see same issues as in 1
I agree with Joe90, just one thing he left out: MonoDevelop can compile .sln and .csproj files because it has a MSBuild implementation.
So point MoMA at your code and if you get a green light it should compile as-is in MonoDevelop.
As a MSCLR junkie I have to admit that Mono has a few 'better' implementations of certain critical functions (mostly to do with encryption). You will get more usability power from these.
Another thing to watch out for is subtle logic errors. If a class is implemented in Mono it does not mean that it will behave the same the MSCLR one (Mono is a cold-room implementation and as such they DO NOT use the original source code). This is really where you will get good results from a well unit-tested code base.
For a good indication of what you should expect, I remember seeing a large amount of #if MONO in the AgsXMPP repository.
You could ideally write a C# application and have it run on the Mono platform. BUT, that will depend on the libraries of MS .NET that has been ported yet to Mono.
Just in case, there is no language constraint, you could consider using other languages like Java, Python, Ruby and the like..
Good Luck!
As many others mention your success will depend on the libraries you use. Mono does have Winforms but I would suggest that you also look at GTK# http://www.mono-project.com/GtkSharp as your windowing library. If you use GTK# you will use a library which is not reverse engineered (as Winforms is in Mono).
My understanding is that "non-gui" .NET 2.0 stuff is pretty much in place with the newest versions of Mono
You don't need mono develop, the whole idea of mono is you can develop for .net and have the same assemblies work on both mono and .net, provided you only use stuff which has been implemented in mono.
Stuff which won't work:
pinvoke,
wpf,
linq to SQL
Stuff which will work:
.net 2.0,
c# 3.0 (including linq to objects and linq to xml),
winforms
If you write your application in Silverlight, anyone with a web browser and the Silverlight plugin can access your app. This is as cross-platform as you're going to get with .NET.