I am trying to reference an IronPython project in a C# Project. They are both in the same solution. I am new to IronPython, so I was just wondering how the referencing works. Does an IronPython generate an assembly at all? All Im trying to do is a pull a simple class into the C# project.
any ideas?
Thanks.
Edit: I'm not getting any error, I just cannot figure out how to reference the Ironpython project.
If you are using IronPython Tools for Visual Studio then an IronPython project will not be compiled. To compile IronPython code to a .NET assembly you can use the IronPython command line compiler pyc or SharpDevelop.
A compiled IronPython assembly cannot be used from a C# application directly without the application hosting the IronPython runtime. When the C# application hosts the IronPython runtime you can then either use the IronPython script files (.py) or the compiled IronPython assembly, as explained in the two articles below, both of which use IronPython 2.6.
Using Python Classes from .NET
Using Compiled Python Classes from .NET
The first article shows an example where the IronPython code mixed in with the C# code. You can alternatively load the IronPython code from files by replacing the call to CreateScriptSourceFromString with CreateScriptSourceFromFile or by using the .NET Framework.
As far as I know IronPython only creates .py script files - you can access the code through the DLR at runtime, there's an example for that here.
Related
I don't know if what I want to do is even possible. I have two C# DotNet DLLs: Parent.DLL and Child.DLL. Both are built with Visual Studio 2010 using .NET Framework 4.
Parent.DLL makes use of routines in Child.DLL. However, at runtime, Parent.DLL and Child.DLL will be in different directories.
Is there a way for Parent.DLL to dynamically load and use Child.DLL at runtime?
I came across this example for use in a console app that is dynamically loading a DotNet DLL and I'm trying to adapt it for use by a DotNet DLL. However, the reference it requires is not recognized when added to the project:
using System.Runtime.Loader;
Is what I am trying to do even possible? Do I need a later version of DotNet?
The phrase you are looking for is reflection. Reflection in the .NET framework allows for dynamically loading in DLL's into the calling assembly assuming they are written in the .NET framework and the methods you are trying to call are public. MSDN has good documentation on it as was already mentioned previously here.
I would like to share common code between a Xamarin.Forms project (C#) and a Qt project (C++).
Have you got a solution?
I try with a Visual C# Class Library which builds a DLL file. I succeeded to reference and use it in the Xamarin.Forms project, but I failed to use it in Qt. I supposed this is because the DLL is compiled from C# code.
Thanks.
If you can put the shared code in your C# dll, you should be able to use it from Xamarin (depending on what libraries it uses) and also call it from your 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 C++ project, created in Visual Studio 2010, which needs to execute code from a C# DLL. I have done so using the
#import "pathname\filename.tlb" raw_interfaces_only
directive, as well as the CoInitialize(NULL) and CoUninitialize() COM calls.
The C# DLL was compiled in VS2012, and targeted .NET 4.5.
I was able to compile and run the project, and it seemed as though everything was fine, but we were noticing differences in some function calls. This was verified by loading the exact same C++ project into VS 2012, turning on /clr in Configuration Properties, and changing the Targeted Framework (of the C++ project) to v4.5 by modifying the .vcxproj file in Notepad.
So, I guess my questions are:
Why does a C++ project need to target a .NET framework? Shouldn't the C# DLL be able to handle that by itself? (Answered by Hans Passant)
Why is it possible to run a C#.NET v4.5 DLL through C++ with /clr off, and not have any warnings that it might not work? (Answered by Hans Passant)
Why do I even get results back from the function call? How is it possible that the C# DLL "works" (returns coherent results) at all? Why does it return different values when targeting .NET v4.0?
Is it possible to use the C# DLL from the C++ code, while still using VS 2010? Or do I need to switch the project to VS 2012?
Thanks in advance.
A native C++ project does not target the .NET Framework at all. The project creation wizard is a bit clumsy, it does not hide the combobox when you create the C++ project.
What framework version the C# DLL needs is established when you register it. Either done automatically when you tick the "Register for COM interop" build setting or explicitly by running Regasm.exe.
That native C++ code can call C# code without trouble is just a goody you get from using COM. Whose basic purpose is to provide the contracts and the glue to allow one language to call code written in another. The CLR has very good COM support and makes it look very easy. That's not the case for C++, writing COM client code is generally unpleasant due to the verbosity and it is pretty easy to make mistakes. Using raw_interfaces_only is a mistake, you don't get the benefit of memory management with smart pointers and error handling with exceptions.
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.