PowerShell 运行空间与 DLR
随着 .NET 4.0 beta 现已推出,以及 .NET 动态语言运行时的更广泛可用性,我猜这些类型的主题将会变得“更热门”。
我对 DLR 和 PowerShell 之间的概念差异感到困惑。 在我看来,如果我想在 .NET 应用程序中提供脚本编写功能,我可以使用 DLR(因此可以在 IronPython 或 IronRuby 中启用脚本编写,或者可用于 DLR 的任何其他 Iron* 语言),或者托管 PowerShell运行空间。
每种方法的优点和缺点是什么? 为什么我会选择其中之一而不是另一个? 作为一种动态语言本身,而且是一流的 .NET 语言,为什么 PowerShell 不也以 DLR 为目标呢?
With the .NET 4.0 beta now available, and thus the wider availability of the .NET Dynamic Language Runtime, I guess these kinds of topics are going to become "hotter".
I'm confused about the conceptual differences between the DLR and PowerShell. It seems to me that if I want to provide scripting capabilities in my .NET app, I can use the DLR (and so enable scripting in IronPython or IronRuby, or whatever other Iron* languages are available for the DLR), or host a PowerShell Runspace.
What are the pros and cons of each method? Why might I choose one over the other? As a dynamic language itself, and a first-class .NET language at that, why doesn't PowerShell also target the DLR?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
在 .NET 4.0 中,DLR 由您可以认为的“DLR v1.0”组成。 这包括调用站点缓存机制、跨语言互操作功能以及对现有 LINQ 表达式树的改进。 这些功能对于实现语言但不托管语言非常有用。
这就是 DLR 1.0 中缺失的部分——所有语言的共享托管故事。 但我们确实以托管 API 的形式开始了这方面的工作,我们在 CodePlex 上提供了 DLR 和 IronPython 项目,并且还在 github 上提供了 IronRuby。 不幸的是,我们认为我们无法在 .NET 4.0 时间范围内使这些 API 达到交付质量,因此我们没有包含它们。 我们特别希望从 Powershell 甚至 VB 和 C# 等其他语言获得更多反馈,以确保我们拥有正确的 API。
因此,除了目前的 IronPython 和 IronRuby 之外,每种语言或多或少都有自己的托管故事。 但我们希望看到所有这些在未来得到统一,以便您的用户可以选择使用什么语言。 但现在 Powershell 还没有可以瞄准的目标。
In .NET 4.0 the DLR consists of what you can consider "DLR v1.0". This includes the call site caching mechanism, the cross-language interop featuers, and the improvements to the existing LINQ expression trees. These are all features which are very useful for implementing a langauge but not hosting a language.
And that's the missing piece in DLR 1.0 - a shared hosting story for all languages. But we do have a start on that in the form of the hosting APIs we ship on CodePlex w/ DLR and IronPython projects and also w/ IronRuby over on github. Unfortunately we didn't think that we could drive these APIs to being ship quality in the .NET 4.0 timeframe so we didn't include them. In particular we want to get more feedback from other languages like Powershell and even VB and C# to make sure we have the right APIs.
Therefore every language more or less has it's own hosting story except for IronPython and IronRuby right now. But we'd love to see all of this get unified in the future so your users can choose what language to use. But right now there's just not something in the box for Powershell to target.
我同意,德国航天中心已经并将继续引发大量良好的讨论。 PowerShell 不是针对 DLR 的。 我不知道为什么。
在 .NET 应用程序中托管 PowerShell 可以在脚本解决方案中启用 PowerShell 对象管道,我认为这是一项关键优势。
有从 IronPython 调用 PowerShell 的示例。
您还可以将 IronPython 嵌入 PowerShell。
IronPython 和 IronRuby 与 Windows 的集成程度与 PowerShell 不同。 如果 PowerShell 能够开箱即用地启用 DLR,那就太好了。
I agree, the DLR has and will continue to generate lots of good discussion. PowerShell is not targeted for the DLR. I don’t know why though.
Hosting PowerShell in a .NET app enables the PowerShell object pipeline in the scripting solution which I believe is one key benefit.
There are examples of calling PowerShell from IronPython.
You can also embed IronPython in PowerShell.
IronPython and IronRuby don’t have the same integration to Windows as does PowerShell. It would be great if PowerShell were DLR enabled out of the box.
Doug 的回答击中了几个关键点,但我认为使用的主要原因PowerShell 作为 .NET 应用程序中的脚本引擎,事实是 PowerShell 正在成为跨 Microsoft 应用程序的主要管理界面,并且维护应用程序的系统管理员将更加熟悉它。
IronPython 和 IronRuby(以及任何其他针对 DLR 的语言)可能仍会为开发人员所熟悉。
Doug's answer hits a few key points, but I think the primary reason to use PowerShell as the scripting engine in a .NET application is the fact that PowerShell is becoming the primary management surface across Microsoft applications and will enjoy a greater familiarity among systems administrators who are maintaining your application.
IronPython and IronRuby (as well as anything other language targeted for the DLR) will likely remain more familiar to the developer audience.
我的看法是,Microsoft 应该基于 DLR 开发其 Backoffice 管理界面,以便可以利用 .NET 中的 Python 和 Ruby(或任何其他基于 DLR 构建的语言)等一流且已经经过验证的语言,因为与我认为他们用 Powershell 重新发明轮子的做法相反。 除了用于管理基础设施应用程序(例如 Exchange)之外,当已经有优秀的语言存在时,我没有动力去学习 Powershell。 我的 0.02 美分。
My take on this is, Microsoft should have developed their Backoffice management interfaces based on the DLR, so that top-notch and already proven languages like Python and Ruby in .NET (or any other language built on the DLR) could be leveraged, as opposed to what I think they did in reinventing the wheel with Powershell. Other than its use to manage infrastructure applications, e.g. Exchange, I don't have an incentive to learn Powershell when there are excellent languages already out there. My .02 cents.
在维基百科上阅读动态语言运行时时来到了这个帖子
我 我想澄清一下,但我的声望还没有达到 50,尽管我所说的很快就会对读者有价值。
在 Doug Finke 的评论(2009 年 7 月 26 日)中,有一个从 IronPython 调用 PowerShell 示例的链接。
该链接通过 codeplex.com 访问,该网站已处于存档模式,并将于 2021 年 7 月 1 日消失。今天查看该链接,codeplex 会将读者引导至 IronPython 的 github 存储库
I came to this thread while reading about Dynamic Language Runtime on Wikipedia
I'd like to clarify, but I'm not at 50 reputation yet, even though what I have to say will be of value to the reader soon.
In Doug Finke's comment (Jul 26 '09) there is a link to examples of calling PowerShell from IronPython.
That link is to through codeplex.com, which is already in archive mode, and will be going away on July 1st, 2021. Looking at the link today codeplex points the reader to the github repo for IronPython