C# 脚本：缺失的拼图

Oleg Shilo

4.88/5 (174投票s)

2004 年 10 月 26 日

MIT

24分钟阅读

1362152

9509

一篇关于 C# 语言“脚本引擎”的文章

请注意，2014 年 CS-Script 已在更宽松的 MIT 许可证下重新发布，源代码和发布仓库现托管在 CodePlex 上。

CodePlex 还托管了 CS-Script 专用的基于 Notepad++ 的 IDE CSScript.Npp。

摘要

本文描述了一个 C# 语言的脚本引擎。以下是所提出的脚本系统的一些主要特性

基于功能齐全的 C#
完全访问 CLR 和 CTS
可以与任何版本的 CLR (.NET 1.1/2.0-3.5) 运行，甚至可能与未来的版本一起运行
通过在此应用程序中托管脚本引擎，可以“脚本化”任何 CLR 应用程序的功能
与常见 IDE 和调试器集成
与操作系统集成
提供全面的文档，例如本地和在线帮助、教程、示例

引言

存在一些非常特殊的编程任务，在传统开发场景中完成这些任务需要付出巨大的努力

design -> coding-> compiling -> application

另一方面，通过使用脚本语言可以非常成功地完成它们。脚本在以下情况下非常有用

开发环境是多变的：预计会频繁修改代码
应用程序逻辑简单：应用程序仅用于非常特定的独立任务
知识产权保护不是问题：源代码是开放的
维护和部署要求非常严格：软件解决方案最好只包含一个文件，并通过简单复制最少数量的文件进行部署
开发速度预计比平时更快：代码由相对较大的块组成

本文介绍了一个我为简化开发配置、测试环境、自动化构建过程、自动化测试和收集测试结果等任务而实现的 C# 语言脚本引擎。这些都是我作为一名活跃的 C#/C++ 程序员通常不喜欢做的事情。

背景

微软没有提供许多足够的脚本解决方案。VBScript 是他们期望用于脚本的语言。尽管通过创建 COM 组件可以中等程度地扩展 VB 功能，但其原生功能极其有限，并且语法概念设计得很糟糕。我相信很多人都清楚使用 VBScript 时的糟糕体验。当 .NET 出现时，我期望 C# 语言的脚本引擎能解决这个问题。然而，这并没有发生。微软没有为 WSH 提供 C# 引擎。MSDN 中给出的理由是：

脚本与 .NET 关系不大，原因有二。首先，WSH 完全依赖于 COM。其次，.NET 语言相对于脚本语言在性能和编程便捷性方面具有显著优势。

微软只为 .NET 提供了三个脚本引擎：旧版 VBScript、旧版 JScript 和 .NET 中间语言 (IL)。我不知道为什么没有 C#。许多开发人员需要一个强大的脚本语言，不是因为它是否适合某个现有软件概念，而是因为我之前提到的所有原因。总结一下，这些是简单快速开发、频繁更改、轻松维护和部署的需求。我认为缺少 C# 脚本引擎是微软的一个营销失误。

当我第一次看到 Python 时，我非常兴奋。终于，有了一个强大而灵活的脚本解决方案。以下是一些“难以匹敌”的 Python 特性：

语言非常丰富
可以预编译并避免“即时”编译
能够进行 GUI 开发
可以创建对象（是的，它是一种面向对象语言）
可以通过使用相同的语言开发模块来扩展
可移植

我使用 Python 的时间越长，就越希望 C# 也能有类似的东西。这个想法一直在酝酿。在网上浏览时，我遇到了一些解决这个问题的尝试。其中一些相当成功（CodeProject 上有几篇关于这个主题的文章），但是我看过的每个 C# 脚本解决方案要么是基于代码中使用一些非 C# 语法元素，要么需要一个额外的自定义格式文件来存储一些额外信息（例如引用的程序集）。但我想要一个能够执行“纯粹”C# 代码的脚本引擎。

一直以来，我感觉可以使用纯 C# 作为脚本语言。其中一个原因是，在 CLR 下运行应用程序与在脚本引擎下运行脚本非常相似。在这两种情况下，执行都发生在运行时系统下，并且在这两种情况下，都会进行语言解释。关于 .NET Framework 的另一个有趣之处是，C# 编译器可以由应用程序托管。所有这些最终使我能够实现一个 C# 脚本引擎。尽管界面有些相似，但该引擎应用程序与 WSH 毫无关系。

CS-Script 引擎

我不想花太多时间描述脚本引擎应用程序。它的代码是可用的，所以请自行查阅。不过，我还是需要说几句。这种应用程序的设计是直截了当的。脚本执行包括两个步骤：编译和执行。编译部分很简单，一些示例代码可以在这里找到。

更具挑战性的任务是实现所有引用程序集的加载。引用程序集的普遍问题是，仅通过分析代码无法确定它们是什么程序集。微软决定以简单的方式处理这个问题：用户通过将它们添加到特殊的 XML 文件 *.csprj 中来显式指定这些程序集。我不能使用这种方法，因为我决定使用纯粹的 *.cs 文件作为运行脚本的唯一输入文件。

我的方法基于这样一个事实：在现实生活中，程序集名称和根 namespace 之间存在很强的关联。例如，System.Windows.Forms 命名空间在 System.Windows.Forms 程序集中实现。类似地，System.XML 命名空间在 System.XML 程序集中实现。这也适用于程序集文件名，它通常是一个 DLL 文件，与程序集名称相同。

[assembly file name] = [assembly name] + .dll

因此，我可以将脚本中的 namespace 解析为程序集。我为全局 (GAC) 和本地程序集都执行此操作。

[namespace] -> [assembly name] -> [assembly file name]

为了找到全局程序集的位置，需要浏览 GAC。不幸的是，没有可用于在 GAC 中导航的 .NET API，只有 COM API。经过一番研究，问题得到了解决。我要感谢 atoenne (CodeProject)、John Renaud (CodeProject) 和 Junfeng Zhang 撰写的关于使用 GAC 的非常有趣的文章。他们帮了我很多。

处理本地程序集与处理全局程序集一样具有挑战性。我使用基于命名空间的预测程序集文件名算法作为起点。然而，正如我之前提到的，namespace 与程序集名称之间只有关联，没有真正的关系。如果程序集文件名与程序集名称不同，情况可能会变得更加复杂。最重要的是，程序集根 namespace 可能与这些名称中的任何一个都不相似。因此，无法可靠地预测引用了哪个程序集。唯一的方法是对脚本目录（当前目录）中找到的程序集应用反射。

然而，仍然无法保证脚本中的所有 namespace 都能被解析。这就是我提供“后门”的原因：程序集可以作为命令行参数显式指定。我从未使用过此功能，因为到目前为止，我所有脚本中的所有 namespace 总是能被解析。我唯一必须施加的限制是，脚本中引用的任何程序集必须位于 GAC 或与脚本相同的文件夹中。

基本上，脚本执行是这样的：用户运行脚本引擎应用程序并指定一个脚本文件作为参数。脚本文件只是一个定义了 static 方法 Main(...) 的 *.cs 文件。引擎将脚本编译成一个程序集，并执行此程序集中一个众所周知的入口点：Main()。这种脚本系统的优点是显而易见的，我将通过说明这种新脚本系统的一些特性来阐释它们：

简单的部署方法：只需将脚本和引擎文件（大约 30 K 大小）带到安装了 .NET 运行时的系统上，即可运行脚本
可移植性：脚本可以在安装了 CLR 的任何系统上运行
基本语言是真正的面向对象语言：使用功能齐全的 C#。我称之为“C# 脚本”，但实际上它是“C#”。“C# 脚本”更能代表执行性质
所有 .NET 功能都可用（FCL、COM 互操作、远程处理）
易于使用的调试器和丰富的 IDE（Microsoft .NET Studio、CLR Debugger）
脚本内的执行模型与任何 .NET 应用程序相同：static void Main()
任何脚本都可以轻松转换为应用程序，反之亦然
优化的解释：脚本中任何语句的解释只进行一次，即使该语句在整个代码中频繁使用
脚本语言是类型安全的：强类型是大多数脚本语言不具备的奢侈品
对于“铁杆”VB 爱好者，动态类型也可用。只需将 Object 作为默认类型，并始终进行装箱/拆箱
所有软件开发任务都可以使用同一种语言完成
脚本应用程序的 GUI 开发变得容易
可扩展性：可以通过使用任何 .NET 语言或 COM 组件编写的新程序集进行扩展

使用 C# 脚本

我已经使用 CS-Script 进行了一些开发，并发现该系统稳定可靠。以下是脚本引擎应用程序的一些特性：

提供两种接口：WinForms 和控制台应用程序
可以执行定义了 Main() 方法的标准 *.cs 文件
可以将编译后的程序集文件存储在与脚本文件相同的位置；如果脚本自上次执行以来未更改，下次可以直接执行该文件，而无需再次编译脚本
可以生成模板脚本文件作为进一步开发的起点
可以从脚本生成可执行文件。因此，无需脚本引擎即可再次运行它
可以从脚本生成程序集，因此它可以像任何其他类库一样使用
脚本引擎对脚本文件扩展名不敏感。用户可以指定任何文件或不带扩展名的文件名。在这种情况下，将假定为 *.cs
如果脚本文件在当前目录中找不到，脚本引擎会在 PATH 环境变量指定的目录中查找它

根据用户需求添加的功能

脚本引擎可以由任何 CLR 应用程序托管。作为下载包的一部分，提供了一个将脚本引擎实现为类库的程序集
脚本引擎可以加载多个脚本。当一个脚本使用另一个脚本的功能时，这非常有用
显式引用的程序集不仅可以从命令行添加，也可以直接从代码中添加

脚本引擎应用程序在 WinForms 模式下名为 cscscript.exe 或 cswscript.exe。准备任何脚本最简单的方法是从命令行执行它：

cscscript /s > Sample.cs

这将在当前目录中生成 Sample.cs 文件。Sample.cs 是一个 C# 源文件。您需要向此文件添加有效的 C# 代码来完成您的特定任务。之后，它可以通过以下命令由脚本引擎编译和执行：cscscript.exe sample.cs

Sample.cs

using System;
using System.Windows.Forms;
class Script
{
 static public void Main(string[] args)
 {
 MessageBox.Show("Just a test!");
 for (int i = 0; i < args.Length; i++)
 {
 Console.WriteLine(args[i]);
 }
 }
}

脚本执行

cs-script_for_cp/ScreenSh.jpg

再次强调，脚本文件包含普通的 C# 代码。没有一个语言语句是只有脚本引擎才能理解，而任何 C# 编译器（Microsoft .NET Studio）都无法理解的。这是 CS-Script 最强的优点之一：

C# Script 不是 C# 的另一种变体。它是 C#，只是编译和执行方式不同。

任何脚本文件也可以使用 .NET Studio 打开、编译和调试，因为它只是 C#。我不得不说，我在这项工作的开始时所获得的超出了我的预期。脚本引擎只是一个应用程序，而且是一个相对原始的应用程序。然而，它的功能可以通过脚本进行扩展。该系统的主要目的是执行可以通过其他脚本改进的脚本。这听起来可能很奇怪，但事实确实如此。这样的脚本可以：

安装脚本引擎（发布到 EnvVar PATH 中）
将任何脚本文件插入预定义的 C# 项目中，并在 .NET Studio 中打开。因此，它已准备好在调试器下运行
创建 shell 扩展，只需右键单击鼠标即可在 .NET Studio 中运行或打开任何脚本文件。如您所见，同一个脚本引擎应用程序现在功能更强大了
从代码片段动态编写 C# 脚本并执行，例如 cscscript code MessageBox.Show("Just a test!") 将弹出消息 "Just a test!"

如您所见，同一个脚本引擎应用程序现在功能更强大了。

CS-Script 包

您可以从本页顶部或我的网页下载整个 CS-Script 包，其中包含脚本引擎、有用的脚本和示例。要安装，您需要从 ZIP 文件中解压所有内容并执行 install.bat。当然，.NET Framework 必须首先安装。安装后，您的环境变量将更新，并且所有 shell 扩展都将创建。严格来说，不需要安装。脚本引擎应用程序是自给自足的，下载后即可立即运行。安装期间执行的唯一操作是调整操作系统环境，以使脚本尽可能方便。以下是我创建并添加到包中的一些非常简单的脚本列表：

NKill.cs - 终止作为命令行参数指定的进程
GetUrl.cs - 获取 URL 内容并将其保存到文件中。可以处理代理身份验证
Debug.cs - 用临时 C# 项目打开脚本，以便在调试器下运行
Install.cs - 安装/卸载 CS-Script shell 扩展，允许通过鼠标右键运行/调试任何脚本
ImportData.cs - 将指定文件中的数据导入 SQL Server 表
ExportData.cs - 将数据从 SQL Server 表导出到指定文件
RunScript.cs - 在后台运行另一个脚本，并将输出重定向到父脚本的脚本
Tick.cs - 简单的脚本，计算指定秒数；用作 RunScript 的演示
SynTime.cs - 从这里获取时间并同步 PC 系统时间
MailTo.cs - 向指定地址发送电子邮件
Reflect.cs - 打印程序集反射信息
Creditentials.cs - 提示并收集用户登录信息
GetOptusUsage.cs - 检索每月数据使用情况。这仅适用于“Optus Australia”客户
Interop.cs - 创建和访问 COM 和 CLR 对象
ImportTickScript.cs - 使用 import 指令导入并执行 tick.cs 脚本
Client.cs Script.cs Common.cs - 使用 CS-Script 脚本扩展任何应用程序的示例
还有其他...

关注点

以前，我的硬盘上有大约一百个 C# 项目。大多数情况下，这些项目只包含大约 100-200 行代码，只是为了测试某个算法或 MSDN 中的代码示例。现在，对于任何编码练习，我只有一个 *.cs 文件。我只需右键单击它，它就会在 .NET Studio 中并准备就绪。这太方便了！脚本还有另一点我真的很喜欢。开发和测试现在可以用同一种编程语言完成。下面是一个简单的例子：

你需要测试你的程序集，例如，它执行打印功能。在运行时条件下，该程序集由主应用程序使用。但是，你需要打印一千次才能获得一些统计数据。如果从主应用程序中进行，意味着用测试代码污染主应用程序。你可以做的是将调用程序集的主应用程序代码复制到 *.cs 文件中，并使用脚本引擎运行它。在这种情况下，程序集在与运行时相同的条件下进行测试，并且测试设计更加优雅。

因此，脚本引擎与脚本结合，就成为一个小型的开发系统。

结论

C# 脚本不应与传统的 C# 开发竞争。它们服务于完全不同的目的。C# 脚本仅仅是 .NET 家族中缺失的东西，是本文标题中的“缺失的拼图”。我很想知道其他人怎么看，并会感谢任何反馈。

反馈

我要感谢所有向我提出建议和想法的人。其中一些已在当前版本的脚本引擎中实现。最常见的问题之一是关于托管脚本引擎。我偶然发现了一个论坛，我因为低估脚本托管的重要性而受到批评。我想他们是对的。尽管从很早的版本（Math.cs 和 MathClient.cs 示例）开始就存在托管脚本引擎的技术可能性，但许多用户希望托管更简单、更直接。根据用户的要求，我实现了全面的脚本引擎托管。所有可能的托管场景都在此处描述。简而言之，托管将涉及：

将脚本编译成程序集，即通过脚本引擎生成脚本程序集
将脚本程序集加载到相应的 AppDomain 中
使用脚本程序集中实现的对象

我在 CSScript 类 (CSScriptLibrary.dll) 中添加了两个方法：

Load - 将脚本编译成程序集并将其加载到当前 AppDomain 中。返回加载的程序集对象
Compile - 将脚本编译成程序集并返回程序集文件名。因此，该程序集可以加载到任何 AppDomain 中

所有这些都允许简单的脚本托管，主机和脚本之间可以不受限制地进行数据交换，只需几行额外的代码即可。请参阅 Client.cs、Script.cs 和 Common.cs 示例。

有一些非常有趣的建议，我没有以它们被提出的方式实现。我将通过一个例子来解释。有一个建议是让脚本引擎接收一个 C# 语句并执行它，而无需实际编写脚本。这个想法很好，但我不想将这种功能放入脚本引擎中。我认为引擎应该是一个简单、可靠和自包含的应用程序，不应功能过载。只有这样它才能健壮稳定。我不想每次决定以不同方式执行脚本时都修改它。我认为所提出的脚本系统可以通过其他脚本和程序集进行扩展，而不是通过重新实现引擎。这样，脚本引擎将免受系统中任何更改的影响。这就是为什么我将建议的功能实现为脚本（code.cs）。因此，在不更改脚本引擎的情况下实现了目的。以下是如何使用此脚本的示例：

cscscript code MessageBox.Show("Just a test!")

脚本 Samples.cs 以类似的方式实现：

cscscript samples: 打印可用示例列表
cscscript samples mailto myMailto.cs: 将“mailto”示例的内容保存到 myMailto.cs 文件中
cscscript samples 1 myScript.cs: 将示例 #1 的内容保存到 myScript.cs 文件中

还有另一个建议是在指定的安全上下文中运行脚本。这可以使用相同的方法实现。例如...

cscscript runas sa:sysadmin myScript

...以用户 sa 和密码 sysadmin 的身份运行 myScript。此外，许多人问我关于运行多个脚本文件的问题。在这种情况下，一个脚本会执行另一个脚本来完成某些工作。我已经实现了这个功能（2005 年 2 月 5 日更新），并且下载已可用。我不得不说，我认为这个功能超出了脚本引擎的最初范围。这是因为，正如我之前提到的，一个需要多个文件的复杂应用程序可以作为传统的 C# 应用程序来实现。因此，没有真正需要使用 CS-Script。然而，从用户的反馈中我看到很多人希望在脚本引擎中看到这个功能。

它的实现方式类似于 C++ 的 #import。Import 指令会在运行时将脚本文件合并在一起。因此，一个脚本中的所有代码都可供另一个脚本使用，反之亦然。语法可在帮助消息中找到（“cscscrip.exe /?”）。为了避免命名冲突，导入可以进行可选的 namespace 重命名。有关详细信息，请参阅提供的示例文件 importTickScript.cs。

我最近添加了对名为 reference 的新指令的支持。它可用于直接从代码中引用程序集。语法可从帮助中获取。您还可以查看 TeeChartForm.cs 示例。如我之前所述，在某些情况下，namespace 无法解析为程序集名称。这是一个非常罕见的情况，但它确实会发生。例如，如果 Steema.TeeChart namespace 在 teechart.lite.dll 程序集中实现。为了解决这个问题，这样的程序集可以作为命令行参数提供。在某些情况下可能不方便，因此我实现了 reference 指令以直接从代码中引用程序集。import 和 reference 指令的语法设计旨在使脚本代码 100% 符合 CLS 规范。

再次感谢所有对本项目感兴趣的人。如果您对文章更新之间的热修复感兴趣，可以从 CS-Script 主页 (www.csscript.net) 下载它们。

历史

2004 年 10 月 26 日
- 初次发布
2004 年 10 月 29 日
- 脚本文件 (install.cs) 更新以修复安装问题
2004 年 11 月 12 日
- 添加到文章
  - 程序集解析算法的描述
  - 新功能的描述
  - 反馈部分
- 可下载项目中的更改
  - 添加了对本地程序集的支持
  - 实现了将脚本编译成 EXE 文件
  - 添加了 CSScriptLibrary 程序集 (CSScriptLibrary.dll)，用于 CLR 应用程序托管脚本引擎
  - 脚本引擎应用程序现在已镜像，cscscript.exe/csc.exe 和 cswscript.exe/csw.exe
2005 年 2 月 5 日
- 添加到文章
  - 更新了关键字列表和反馈部分
- 可下载项目中的更改
  - 添加了对运行多个脚本文件的支持
- 更新了 debug.cs 脚本。它现在能够解析代码中所有引用的 namespace 或对其他脚本的引用，并生成相应的 Visual Studio 项目
2005 年 6 月 10 日
- 添加到文章
  - 更新了反馈部分
- 可下载项目中的更改
  - 添加了从代码中引用程序集的支持
  - 更新了 debug.cs 脚本。它现在能够将代码中引用的程序集添加到相应的 Visual Studio 项目
2005 年 7 月 20 日
- 添加到文章
  - 更新了反馈部分
- 可下载项目中的更改
  - 添加了对 .NET 2.0 Framework 的支持
  - 改进了对脚本托管的支持
  - 添加了对 Visual Studio 8.0、SharpDevelop 和 Microsoft CLR Debugger 的支持
2005 年 8 月 16 日
- 可下载项目中的更改
  - 修复了阻止安装 Visual Studio 2005 shell 扩展的错误
  - 添加了对脚本中 [STAThread] 和 [MTAThread] 属性的支持
  - 添加了一些新的示例脚本
2005 年 10 月 27 日
- 在文章开头添加了更新描述 (v 1.2)
2007 年 5 月 25 日
- 文章更新。
2007 年 7 月 19 日
- 文章和下载已更新
2008 年 4 月 8 日
- 文章更新。
2009 年 2 月 28 日
- 文章更新。
2009 年 6 月 22 日
- 文章更新。
2009 年 9 月 29 日
- 文章更新。

C# 脚本： 缺失的拼图

摘要

引言

最新更新

背景

CS-Script 引擎

使用 C# 脚本

Sample.cs

CS-Script 包

关注点

结论

反馈

历史

C# 脚本：缺失的拼图