铁蟒 / 铁红宝石 EXE
我一直梦想着用脚本语言创建一个“真正的可执行文件”。 有了基于 DLR 的 Python 和 Ruby 实现，这是否更接近现实了？
我想创建一个“真正的应用程序”：
- Windows 窗体应用程序
- 控制台应用程序
- Windows 服务
并且让分发单元成为已编译的 exe。
这可能吗？ 或者 MS 刚刚创建了基于 .NET 的脚本文件解释器？
如果您正在这样做，您将如何构建您的应用程序/项目？ 您是否使用 C# 和 DLR 代码的混合体？
I've always had this dream of creating a 'real exe' from a scripting language. With the available of DLR-based implementations of Python and Ruby, is this getting any closer to reality?
I'd like to create a 'real application':
- A Windows Forms App
- A Console App
- A Windows Service
And have the unit of distribution be a compiled exe.
Is this possible? Or has MS just created script file interpreters based on .NET?
If you are doing this, how are you structuring your applications / projects? Are you using a hybrid of C# and DLR code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
IronPython 或 IronRuby 项目可以很好地编译为 dll 或可执行文件，并且在各个方面都是“真正的”可执行文件，但运行它们的人必须安装相关的 .Net 框架和依赖项（依赖项可能存在于默认情况下位于同一目录，但必须安装框架）。 与 Visual Studio 的集成仍然不存在，但像 IronPythonStudio 这样的项目使用免费的 VS Shell 效果很好。 DLR 作为 VS 2010 中 c# 动态的依赖项的存在意味着与 Iron* 组的 VS 集成将成为一个更容易的目标和更高的优先级。
结果绝不会被解释（CIL 在运行时或通过 ngen（如果需要）被编译成机器代码），并且 DLR 的某些方面意味着某些操作以与后期绑定类似的方式推迟，但通过一些复杂的缓存机制更加强大和关键与天真的解释器相比，这使得它相对较快。
许多传统的解释型脚本语言正在创建自己的基于 VM 的编译策略或利用现有策略（例如 JVM、.Net CLR 或开放策略，例如 LLVM），因为这在许多常见情况下会显着提高性能。
就 Iron* 语言而言，以 MS CLR 作为基础的好处是，生成的可执行文件可以在最常见操作系统系列的绝大多数安装上“正常工作”。 与 Java 不同的是，在许多操作系统中，jar 文件不能通过直接单击 / 或通过 shell“执行”来“运行”。 不利的一面是，与基于 JVM 或 LLVM 的解决方案相比，这降低了互操作性，其中平台支持更广泛，但不可避免地在操作系统集成方面更加多样化。
An IronPython or IronRuby project can be compiled to a dll or executable just fine and will be 'real' executables in every way with the proviso that the person running them must have the relevant .Net framework and dependencies installed (dependencies may be present in the same directory by default instead but the framework must be installed). The integration with Visual Studio is still not there but projects like IronPythonStudio use the free VS Shell to good effect. The existence of the DLR as a dependency for c# dynamic in VS 2010 should mean that integration with VS from the Iron* groups becomes an easier goal and a higher priority.
The result is in no way interpreted (the CIL is jitted into machine code at runtime or via ngen if desired) and certain aspects of the DLR mean some actions are deferred in a similar fashion to latebinding but more powerfully and crucially with some sophisticated caching mechanisms to allow this to be relatively fast compared with naive interpreters.
Many traditionally interpreted scripting languages are creating their own VM based compilation strategies or leverage existing ones (like the JVM, the .Net CLR or open ones like the LLVM) since this leads to significant performance increases in many common cases.
In the case of the Iron* languages the benefit of the MS CLR as a basis is that the resulting executables 'Just Work' on the vast majority of installations of the most common OS family. Contrast to Java where a jar file is not 'runnable' by directly clicking / or 'executing' via the shell in many operating systems. The flipside from this is that this reduces interoperability compared to say a JVM or LLVM based solution where the platform support is broader but, inevitably, more diverse in OS integration.
您可以使用 Py2Exe 从常规 Python 创建 exe 文件。 但不应该有任何事情阻止您使用 Visual Studio 或 SharpDevelop 通过 IronPython 创建 exe 文件
You can create exe's from regular python using Py2Exe. But there shouldn't be anything preventing you from creating exes with IronPython using Visual Studio or SharpDevelop
虽然与 Iron* 问题没有直接关系，但对于想要从 python 脚本中获取二进制文件的人来说可能会感兴趣： pyinstaller
在 Windows 下工作（32 位和 64 位）、Linux（32 位和 64 位）和 Mac OS X（仅限 32 位）
可在从 1.5 到 2.7 的任何版本的 Python 下运行
although not directly related to iron* question, might be interesting for someone wanting binaries from python scripts: pyinstaller
works under Windows (32-bit and 64-bit), Linux (32-bit and 64-bit) and Mac OS X (32-bit only)
works under any version of Python from 1.5 up to 2.7