PowerShell运行空间与DLR

在.NET 4.0中,DLR由您可以认为的“DLR v1.0”组成。这包括调用站点缓存机制、跨语言互操作特性,以及对现有LINQ表达式树的改进。这些功能对于实现语言非常有用,但不支持语言。

这是DLR1.0中缺失的部分——所有语言的共享托管故事。但是我们已经从托管API的形式开始,我们在codeplex w/dlr和ironpython项目上发布了API,在github上也发布了ironruby。不幸的是,我们认为我们不能在.NET 4.0时间框架内推动这些API实现交付质量,因此我们没有将它们包括在内。特别是,我们希望从PowerShell、甚至是VB和C等其他语言获得更多反馈,以确保我们拥有正确的API。

因此,除了Ironpython和IronRuby之外,每种语言或多或少都有自己的托管故事。但是我们希望看到所有这些在将来都能统一起来,这样你的用户就可以选择使用哪种语言了。但是现在PowerShell的目标还没有。

我同意,DLR已经并将继续进行大量的讨论。PowerShell不是DLR的目标。我不知道为什么。

在.NET应用程序中托管PowerShell可以启用脚本解决方案中的PowerShell对象管道,我认为这是一个关键好处。

有一些例子 calling PowerShell from IronPython .

你也可以 embed IronPython in PowerShell .

Ironpython和IronRuby Don_t与PowerShell具有相同的Windows集成。如果能在开箱即用的情况下启用PowerShell,那就太好了。

Doug's answer 触及几个关键点,但我认为在.NET应用程序中使用PowerShell作为脚本引擎的主要原因是PowerShell正在成为整个Microsoft应用程序的主要管理面,并将在维护您的应用程序的系统管理员中享有更大的熟悉度。

Ironpython和IronRuby(以及针对DLR的任何其他语言)很可能对开发人员的读者更加熟悉。

我的看法是,微软应该已经开发了基于DLR的后台管理界面,这样就可以利用诸如.NET中的python和ruby(或基于DLR的任何其他语言)等顶级且已经被验证的语言,而不是我认为他们在用PowerShell重新设计方向盘时所做的。除了用于管理基础设施应用程序(如Exchange)之外,当已经有优秀的语言存在时,我没有学习PowerShell的动机。我的0.02美分。