关于C＃：向.NET应用程序添加脚本功能

我有一个用C＃编写的小游戏。 它使用数据库作为后端。 它的
交易纸牌游戏，我想将纸牌的功能实现为脚本。

我的意思是，我本质上有一个接口ICard，卡类实现该接口(public class Card056: ICard)，并且包含游戏调用的功能。

现在，为了使事物可维护/可修改，我希望将每个卡的类作为源代码存储在数据库中，并在首次使用时进行编译。 因此，当我必须添加/更改卡时，只需将其添加到数据库中并告诉我的应用程序刷新，而无需进行任何程序集部署(尤其是因为我们要谈论的是每张卡1个程序集，这意味着数百个程序集) 。

那可能吗？ 从源文件注册一个类，然后实例化它，依此类推。

语言是C＃，但如果可以用任何.NET语言编写脚本，则可以额外获得好处。

Oleg Shilo的C＃脚本解决方案(位于The Code Project)确实是在您的应用程序中提供脚本功能的出色介绍。

另一种方法是考虑专门为脚本编写的语言，例如IronRuby，IronPython或Lua。

IronPython和IronRuby现已上市。

有关嵌入IronPython的指南，请阅读
如何通过10个简单的步骤将IronPython脚本支持嵌入到您现有的应用程序中。

Lua是游戏中常用的脚本语言。有一个适用于.NET的Lua编译器，可从CodePlex获得-http://www.codeplex.com/Nua

如果您想了解有关在.NET中构建编译器的信息，那么该代码库是一本不错的书。

换一个角度来看，尝试使用PowerShell。有许多将PowerShell嵌入到应用程序中的示例-这是一个有关该主题的详尽项目：
Powershell隧道

您也许可以使用IronRuby。

否则，我建议您有一个放置预编译程序集的目录。然后，您可以在数据库中对程序集和类进行引用，并使用反射在运行时加载适当的程序集。

如果您确实想在运行时进行编译，则可以使用CodeDOM，然后可以使用反射来加载动态程序集。 Microsoft文档文章可能会有所帮助。

如果您不想使用DLR，则可以使用Boo(具有解释器)，也可以考虑使用CodePlex上的Script.NET(S＃)项目。使用Boo解决方案，您可以在编译脚本之间进行选择，也可以使用解释器进行选择，而Boo通过其开放的编译器体系结构提供了一种不错的脚本语言，灵活的语法和可扩展的语言。但是，Script.NET看起来也不错，您可以轻松地扩展该语言及其开放源代码项目，并使用非常友好的Compiler Generator(Irony.net)。

您可以使用任何DLR语言，它们提供了一种真正轻松地托管自己的脚本平台的方法。但是，您不必为此使用脚本语言。您可以使用C＃并使用C＃代码提供程序进行编译。只要将其加载到自己的AppDomain中，就可以将其加载和卸载到您的心脏内容中。

我正在将LuaInterface1.3 + Lua 5.0用于NET1.1应用程序。

Boo的问题在于，每次您动态分析/编译/评估代码时，它都会创建一组boos类，因此您将发生内存泄漏。

另一方面，Lua并不会那样做，因此它非常稳定并且工作出色(我可以将对象从C＃传递到Lua并向后传递)。

到目前为止，我还没有将它放在PROD中，但是看起来非常有前途。

使用LuaInterface + Lua 5.0在PROD中确实存在内存泄漏问题，因此我使用Lua 5.2并通过DllImport直接链接到C＃。内存泄漏在LuaInterface库内部。

Lua 5.2：从http://luabinaries.sourceforge.net和http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download下载

一旦这样做，我所有的内存泄漏都消失了，应用程序非常稳定。

我建议使用LuaInterface，因为它已经完全实现了Lua，而Nua似乎并不完整，并且可能未实现某些非常有用的功能(协程等)。

如果您想使用一些外部预包装的Lua模块，则建议使用与1.5.x相似的东西，而不是2.x系列，后者构建完全托管的代码并且不能公开必要的C API。

我的部门销售的主要应用程序提供了与客户定制非常相似的功能(这意味着我无法发布任何来源)。我们有一个加载动态VB.NET脚本的C＃应用??程序(尽管可以轻松支持任何.NET语言-之所以选择VB，是因为定制团队来自ASP背景)。

使用.NET的CodeDom，我们使用VB CodeDomProvider从数据库编译脚本(令人讨厌的是，它默认为.NET 2，如果要支持3.5功能，则需要通过" CompilerVersion" =" v3.5"传递字典。到其构造函数)。使用CodeDomProvider.CompileAssemblyFromSource方法对其进行编译(您可以传递设置以强制其仅在内存中进行编译。

这将导致数百个程序集在内存中，但是您可以将所有动态类的代码放到一个程序集中，并在发生任何更改时重新编译整个程序。这样做的好处是，您可以在测试时添加一个标志以使用PDB在磁盘上进行编译，从而允许您通过动态代码进行调试。

是的，我曾考虑过这一点，但很快就发现另一种特定于域的语言(DSL)可能会有点过多。

本质上，他们需要以可能无法预测的方式与我的游戏状态互动。例如，一张牌可以有一条规则："当这张牌进入游戏时，您的所有亡灵小兵都会对飞行中的敌人获得+3攻击，除非有祝福的敌人"。由于交易纸牌游戏是基于回合制的，因此GameState Manager将触发OnStageX事件，并允许这些纸牌以其需要的任何方式修改其他纸牌或GameState。

如果尝试创建DSL，则必须实现相当大的功能集并可能不断对其进行更新，这将维护工作转移到了另一部分，而没有实际删除它。

这就是为什么我想使用"真正的" .NET语言来本质上能够触发事件并使卡以任何方式(在代码访问安全性的限制内)操纵游戏状态的原因。

.NET的下一个版本(5.0？)讨论了如何打开"编译器即服务"，这将使直接脚本评估成为可能。