使用嵌入式（托管）IronPython 为 C# 应用程序分发 DLR 运行时
我们正在构建一个商业（封闭/专有）Intranet 应用程序，该应用程序使用托管的 IronPython (2.7)，面向 .NET 4.0。
您建议采用什么方法来确保 DLR 运行时（Microsoft.Scripting.dll 和 Microsoft.Dynamic.dll - 均包含在 IronPython 2.7 二进制发行版中）在运行时可用？
它们都根据 Apache 许可证获得许可，因此包含在我们的软件中不会有问题。可能的替代方案是确保它们在 GAC 中可用。
DLR 开发人员的意图似乎是越来越多的 DLR 最终将出现在 .NET Framework/CLR 中（大概在 System.Core 下）。
任何想法或考虑都值得赞赏。
We're building a commercial (closed/proprietary) intranet application which makes used of hosted IronPython (2.7), targeting .NET 4.0.
What approach would you recommend for ensuring the DLR runtimes (Microsoft.Scripting.dll & Microsoft.Dynamic.dll - both included in the IronPython 2.7 binary distribution) are available at runtime?
They're both licensed under Apache license so including with our software wouldn't be a problem. Potentially an alternative would be ensuring they're available in the GAC.
It seems the intention of the DLR developers is that more and more of the DLR will eventually end up in the .NET framework/CLR (presumably under System.Core).
Any thoughts or considerations are appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最好的办法是将 DLR DLL 包含在应用程序中的 IronPython DLL 旁边。将它们放入 GAC 将影响使用 DLR 的系统上的所有其他应用程序，这可能不是您想要的，除非您完全控制所涉及的系统。
.NET 4 中的内容可能是要纳入的 DLR 范围； Microsoft 不再参与 DLR 的开发。
The best thing to do is include the DLR DLLs in your application next to the IronPython DLLs. Putting them in the GAC will affect every other application on the system that uses the DLR, which is probably not what you want unless you have complete control of the systems involved.
What's in .NET 4 is probably the extent of the DLR that's going to go in; Microsoft is not involved in the development of the DLR anymore.