.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 に欠けていた部分です。つまり、すべての言語の共有ホスティング ストーリーです。しかし、私たちは、DLR および IronPython プロジェクトを使用して CodePlex で出荷するホスティング API の形で、また github で IronRuby を使用して、その開始をしています。残念ながら、これらの API を .NET 4.0 のタイムフレームで出荷品質にすることができるとは考えていなかったため、それらを含めませんでした。特に、適切な API があることを確認するために、Powershell や VB や C# などの他の言語からより多くのフィードバックを得たいと考えています。
したがって、現在、IronPython と IronRuby を除いて、すべての言語には多かれ少なかれ独自のホスティング ストーリーがあります。しかし、ユーザーが使用する言語を選択できるように、これらすべてが将来的に統合されることを望んでいます。しかし、現時点では、Powershell がターゲットにするものが何もありません。
DLR はこれまでも、そしてこれからも多くの良い議論を生み出し続けることに同意します。PowerShell は DLR の対象ではありません。理由はわかりませんが。
.NET アプリで PowerShell をホストすると、スクリプト ソリューションで PowerShell オブジェクト パイプラインが有効になり、これは重要な利点の 1 つだと思います。
IronPython から PowerShellを呼び出す例があります。
IronPython を PowerShell に埋め込むこともできます。
IronPython と IronRuby は、PowerShell と同じように Windows に統合されていません。PowerShell がデフォルトで DLR 対応になっていれば素晴らしいことです。
Doug の回答はいくつかの重要なポイントに当てはまりますが、PowerShell を .NET アプリケーションのスクリプト エンジンとして使用する主な理由は、PowerShell が Microsoft アプリケーション全体の主要な管理面になりつつあり、システム管理者の間でより親しみやすくなるという事実だと思います。アプリケーションを維持しています。
IronPython と IronRuby (および DLR を対象とするその他の言語) は、開発者の聴衆にとってより馴染みのあるものであり続けるでしょう。
これに対する私の見解は、Microsoft は DLR に基づいてバックオフィス管理インターフェイスを開発するべきだったので、.NET の Python や Ruby (または DLR 上に構築されたその他の言語) のような一流で既に実績のある言語を活用できるようにするべきだったということです。彼らがPowershellで車輪を再発明したと私が思うこととは対照的です. Exchange などのインフラストラクチャ アプリケーションの管理に使用する以外は、優れた言語が既に存在する場合に Powershell を学習する動機がありません。私の0.02セント。