随着 .NET 4.0 测试版的推出，以及 .NET 动态语言运行时更广泛的可用性，我猜这类主题将会变得“热门”。
我对 DLR 和 PowerShell 之间的概念差异感到困惑。在我看来，如果我想在我的 .NET 应用程序中提供脚本功能，我可以使用 DLR（从而在 IronPython 或 IronRuby 或任何其他可用于 DLR 的 Iron* 语言中启用脚本），或者托管一个 PowerShell运行空间。
每种方法的优缺点是什么？为什么我会选择其中之一？作为一种动态语言本身，以及一流的 .NET 语言，为什么 PowerShell 也不针对 DLR？
在 .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 的盒子里没有东西可以瞄准。
我同意，DLR 已经并将继续产生很多好的讨论。PowerShell 不针对 DLR。我不知道为什么。
在 .NET 应用程序中托管 PowerShell 可以在脚本解决方案中启用 PowerShell 对象管道，我认为这是一个关键优势。
有从 IronPython 调用 PowerShell的示例。
您还可以在 PowerShell 中嵌入 IronPython。
IronPython 和 IronRuby 与 Windows 的集成与 PowerShell 不同。如果 PowerShell 能够开箱即用地启用 DLR，那就太好了。
Doug 的回答提到了几个关键点，但我认为在 .NET 应用程序中使用 PowerShell 作为脚本引擎的主要原因是 PowerShell 正在成为跨 Microsoft 应用程序的主要管理界面，并且将在系统管理员中更加熟悉正在维护您的应用程序。
IronPython 和 IronRuby（以及针对 DLR 的任何其他语言）可能仍会为开发人员受众所熟悉。
我对此的看法是，微软应该基于 DLR 开发他们的 Backoffice 管理界面，以便可以利用一流且已经证明的语言，如 .NET 中的 Python 和 Ruby（或任何其他基于 DLR 构建的语言），因为与我认为他们用 Powershell 重新发明轮子所做的相反。除了用于管理基础架构应用程序（例如 Exchange）之外，当已经有优秀的语言出现时，我没有学习 Powershell 的动力。我的 0.02 美分。
我在阅读维基百科上的动态语言运行时时来到这个线程
我想澄清一下，但我的声望还不到 50，尽管我要说的内容很快就会对读者有价值。
在 Doug Finke 的评论（2009 年 7 月 26 日）中，有一个链接指向从 IronPython 调用 PowerShell 的示例。
该链接指向已处于存档模式的 codeplex.com，该链接将于 2021 年 7 月 1 日关闭。今天查看该链接，codeplex 将读者指向 IronPython 的 github 存储库