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.
Related
I'm working on the port of the C# UWP project to Uno-Platform. The original project references a lot of logic from C++ DLLs. The interface between C# and C++ library is rather big to write PInvoke wrappers manually.
Is there any complete solution to automate the calling of C++ library methods from .NET?
The Uno Platform does not provide anything specific for this type of scenarios, and relies on what .NET already provides (P/Invoke in this case).
You may want to take a look at https://github.com/EgorBo/CppPinvokeGenerator or https://github.com/xoofx/CppAst.NET to generate C# from the C++ code.
As far as I know a C# project can be added to Unity3d in 2 forms. As DLL or uncompiled project.
What are the pros and cons of both? Will they work cross platform (Android/iOS/WinPhone)?
To compile as DLL - do I just use MonoDevelop or Visual Studio to new class library project and select .NET 3.5 and compile?
How do you add a uncompiled project to Unity3d?
Will they work Cross platform(Android/iOS/WinPhone)?
Yes. You can create a library project in Xamarin Studio/MonoDevelop/or Visual Studio. If you do not include platform-specific functions, it will be then cross platform.
To compile as DLL - Do I just use MonoDevelop or Visual Studio to new class library project and select .NET 3.5 and compile?
See this tutorial.
Well Well Well too many question in a single post. Try to answer one by one:
Unity Offical Docs provide much help:
Question
As far as I know a C# project can be added to Unity3d in 2 forms. As DLL or uncompiled project.
To compile as DLL - do I just use MonoDevelop or Visual Studio to new class library project and select .NET 3.5 and compile?
Usually, scripts are kept in a project as source files and compiled by
Unity whenever the source changes. However, it is also possible to
compile a script to a dynamically linked library (DLL) using an
external compiler. The resulting DLL can then be added to the project
and the classes it contains can be attached to objects just like
normal scripts.
It is generally much easier to work with scripts than DLLs in Unity.
However, you may have access to third party Mono code which is
supplied in the form of a DLL. When developing your own code, you may
be able to use compilers not supported by Unity (F#, for example) by
compiling the code to a DLL and adding it to your Unity project. Also,
you may want to supply Unity code without the source (for an Asset
Store product, say) and a DLL is an easy way to do this.
More
What are the pros and cons
About dll:
Pros
You can build DLLs separately.
It could be faster to re-build one DLL
Cons
Calling code from DLL is slower
It would be slower to re-build hole project with all DLLs
Function names are visible. It is easier to reverse code that uses
dynamic DLLs
You can find more on here, here and specially on Google, our best friend:)
How do you add a uncompiled project to Unity3d?
Ans: What do you mean by uncompiled project? You mean scripts? then it is usually Copy\Paste inside asset folder simply.
When you open your Unity project in an IDE (for example Visual Studio), it is a solution with two projects, one for game scripts and one for editor scripts. You can add more projects to the solution through your IDE of choice. In order for this to work, you need to set projects target framework to one that is compatible with Unity (which uses a subset of Mono), for example Unity 3.5 .net full Base Class Libraries. Unfortunately .NET PCL is not supported.
You can reference your (or third party) library in any of the projects as usual, just remember it also has to be compatible with Unity.
Wether your code will work on all the platforms actually depends on what you use. On platform specific limitations refer to http://docs.unity3d.com/Manual/PlatformSpecific.html.
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
I have the source code of a C# program. I want to create a DLL out of it which I want to use in C++.
Is it possible to create a native DLL in Visual Studio 2008 which can be used in C++?
native <-> .Net interop is one of my pet disciplines, which is why I needed this as straightforward and reliable as possible.
The result was that I made me an MSBuild task which I just need to drag into a project to allow me to export static methods from pretty much any .Net language. And since the whole marshalling infrastructure works for exports as well, you can do pretty much anything with it that you want (like passing native/managed objects as IUnknown).
The resulting assembly will look to the consuming process like a real DLL, which means you can't have it to scale up to 64bit automatically anymore.
However, since you do have native bits in your application, you already have this issue anyways. ;-)
When you do not specifiy the CPU target in your C# project, my task will emit a warning that it created a folder for all targets (x86,x64 and Itanium), and there you'll have *.dll and *.pdb for each platform.
If you want the program to be native, and not managed, you'll need to port it to C++, instead of using C#.
That being said, you can compile it in C# into a library, and use it from C++ by using C++/CLI. This just requires that you compile the files that use the C# library with the /clr flag. This provides C++ access to the .NET framework, and lets you use libraries made in C# directly from C++.
Alternatively, you can use .NET's COM interop to expose the C# class(es) as COM objects, and then use those from native C++.
It is possible in Visual Studio 2008, but you're not going to be able to write it using C#.
To create a native DLL, you'll have to write your code using one of the unmanaged C++ project types.
You can expose the DLL to COM. Have a look here for some examples.
yes you can.
you need to create second project.
the project must be unmanaged (like "visual c++"->class library).
the name of this procedure is "calling from unmanaged code to managed code".
good to read unmanaged to managed (codeproject)
you must be aware, that any computer that using your dll must have preinstalled DotNet and Visual C++ Redistributable Package
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