随着 .NET 4.0 测试版的推出，以及 .NET 动态语言运行时更广泛的可用性，我猜这类主题将会变得“更热门”。
我对 DLR 和 PowerShell 之间的概念差异感到困惑。在我看来，如果我想在我的 .NET 应用程序中提供脚本功能，我可以使用 DLR（从而在 IronPython 或 IronRuby 或任何其他可用于 DLR 的 Iron* 语言中启用脚本），或者托管一个 PowerShell运行空间。
每种方法的优缺点是什么？为什么我会选择其中之一？作为一种动态语言本身，以及一流的 .NET 语言，为什么 PowerShell 不也针对 DLR？
【问题讨论】：
标签： .net powershell scripting dynamic-language-runtime
我在阅读维基百科上的 Dynamic Language Runtime 时来到这个帖子
我想澄清一下，但我的声望还不到 50，尽管我要说的内容很快就会对读者有价值。
在 Doug Finke 的评论（2009 年 7 月 26 日）中，有一个链接指向从 IronPython 调用 PowerShell 的示例。
该链接指向已处于存档模式的 codeplex.com，将于 2021 年 7 月 1 日停用。今天查看该链接 codeplex 将读者指向github repo for IronPython
【讨论】：
我对此的看法是，微软应该基于 DLR 开发他们的 Backoffice 管理界面，以便可以使用一流且已经证明的语言，如 .NET 中的 Python 和 Ruby（或任何其他基于 DLR 构建的语言）杠杆，而不是我认为他们用 Powershell 重新发明轮子所做的事情。除了用于管理基础设施应用程序，例如交换，当已经有优秀的语言存在时，我没有学习 Powershell 的动力。我的 0.02 美分。
【讨论】：
在 .NET 4.0 中，DLR 包含您可以考虑的“DLR v1.0”。这包括调用站点缓存机制、跨语言互操作功能以及对现有 LINQ 表达式树的改进。这些都是非常有用的功能，对于实现一种语言但不托管一种语言。
这就是 DLR 1.0 中缺失的部分 - 所有语言的共享托管故事。但我们确实以托管 API 的形式开始了这方面的工作，我们在 CodePlex w/ DLR 和 IronPython 项目以及在 github 上使用 IronRuby 提供托管 API。不幸的是，我们认为我们无法在 .NET 4.0 时间范围内推动这些 API 达到交付质量，因此我们没有将它们包括在内。特别是我们希望从其他语言（例如 Powershell 甚至 VB 和 C#）获得更多反馈，以确保我们拥有正确的 API。
因此，除了 IronPython 和 IronRuby 目前，每种语言或多或少都有自己的托管故事。但我们希望看到所有这些在未来得到统一，以便您的用户可以选择使用哪种语言。但是现在 Powershell 的盒子里没有东西可以定位。
【讨论】：
Doug's answer 提到了几个关键点，但我认为在 .NET 应用程序中使用 PowerShell 作为脚本引擎的主要原因是 PowerShell 正在成为跨 Microsoft 应用程序的主要管理界面，并且会更加熟悉在维护您的应用程序的系统管理员中。
IronPython 和 IronRuby（以及针对 DLR 的任何其他语言）可能仍会为开发人员受众所熟悉。
【讨论】：
我同意，DLR 已经并将继续引发大量良好的讨论。 PowerShell 不针对 DLR。我不知道为什么。
在 .NET 应用程序中托管 PowerShell 可以在脚本解决方案中启用 PowerShell 对象管道，我认为这是一个关键优势。
有calling PowerShell from IronPython的例子。
你也可以embed IronPython in PowerShell。
IronPython 和 IronRuby 与 Windows 的集成与 PowerShell 不同。如果 PowerShell 能够开箱即用地启用 DLR，那就太好了。
【讨论】：