An IronPython or IronRuby project can be compiled into a DLL or the executable is just fine and will be “real” executables in all respects with the condition that the person who runs them must have the appropriate .Net infrastructure and dependencies (dependencies may be be present in the same directory by default, but the infrastructure must be installed). Integration with Visual Studio is still missing, but projects like IronPythonStudio use the free VS Shell for a good effect. The existence of DLR as a dependency for C # dynamic in VS 2010 should mean that integration with VS from Iron * groups becomes an easier task and a higher priority.
The result is not interpreted in any way (if necessary, CIL in machine code is placed in machine code at runtime or via ngen), and some aspects of DLR mean that some actions are delayed similarly to a late transition, but more powerful and critical with some complex caching mechanisms. so that it is relatively fast compared to naive translators.
Many traditionally interpreted scripting languages create their own VM-based compilation strategies or use existing ones (for example, JVM, .NET CLR or open-source, such as LLVM ), as this leads to a significant increase in performance in many common cases.
In the case of Iron * languages, the advantage of MS CLR as a basis is that the resulting “Just Work” executable files on the vast majority of installations of the most common OS family. Contrast to Java, where the jar file is not “runnable” by directly clicking / or “running” through the shell on many operating systems. The difference from this is that it reduces interoperability compared to a JVM or LLVM solution, where platform support is broader, but inevitably more diverse in OS integration.
ShuggyCoUk
source share