简介一套支持.NET 4.0的智能C#脚本编辑器源码面向自动化软件工程师和需在平台内嵌入脚本能力的开发者用于在系统架构完成后仍能通过脚本快速调整业务逻辑。编辑器使用VS2015开发可实现代码颜色高亮、自定义类及自定义库中的对象字段属性智能提示输入体验接近VS编译器能够显著降低主程序频繁改版带来的维护成本。整个压缩包仅1.89MB共76个文件核心为18个cs源码文件、17个dll类库、6个pdb调试文件以及resources资源、config配置和可执行示例解决方案中包含演示窗体、脚本提供器与自定义测试类便于直接定位关键实现。作者作为自动化软件控制工程师已在实际项目中应用验证目前已有1090人学习使用适合用来研究脚本引擎交互、智能联想触发机制及自定义程序集加载也可作为C#脚本编辑器二次开发的起点。1. 为什么在.NET 4.0上还要自己做智能提示脚本编辑器做过C#上位机或者自动化测试框架的人多半遇到过这种尴尬业务逻辑经常变不能每次改动都重新编译整个WinForms程序于是想塞一个脚本引擎进去让用户在界面上写几行C#代码就能改行为。市面上现成的C#脚本编辑器插件不少但一提到要跑在.NET 4.0的旧项目里还要带智能提示大部分方案直接哑火——要么依赖.NET Framework 4.7.2以上的新API要么编辑器控件体积大得离谱。这套智能C#脚本编辑器源码的价值就在这它把“运行时编译C#代码”和“代码补全提示”两件事都压在了.NET 4.0这个老框架上让老项目也能获得接近Visual Studio的编辑体验。适合的人群很具体还在维护.NET 4.0时代WinForms/WPF项目的工程师、做C#上位机需要脚本化二次开发的团队以及想给自家自动化工具嵌一个脚本面板的开发者。2. 运行时编译与代码补全先搞懂这两条技术路线2.1 为什么选Roslyn而不是CodeDOM在.NET 4.0上做运行时编译常见路线有两条CodeDOM和Roslyn。CodeDOM是微软老牌的动态编译方案通过CSharpCodeProvider把源码字符串编译成程序集然后反射调用。它的优点是框架自带、部署简单缺点是编译速度慢、错误信息难读而且完全没有任何代码分析能力——想做智能提示就得自己去解析源码工作量直接起飞。Roslyn是编译器即服务Compiler as a Service把编译过程拆成了词法分析、语法分析、符号绑定、编译成IL等公开的API开发者可以直接拿到语法树。智能提示的本质就是基于语法树做语义分析然后从符号表里捞可用的成员。Roslyn的Microsoft.CodeAnalysis.CSharp包虽然官方建议新项目用但它有一部分版本仍然保留了net40目标框架支持这正是这套源码能在.NET 4.0上落地的前提。我一般会先看项目的运行时约束再选如果脚本只是简单计算用CodeDOM省心一旦要做成员补全、参数列表提示、错误波浪线Roslyn是唯一靠谱选择。这套编辑器源码显然走的是后者而且它在引用版本上做了固定处理避免新版本Roslyn默认不支持net40的坑。2.2 智能提示的两个层次字符串扫描和语义补全智能提示不是只有一种实现深度。最粗糙的做法是正则扫描用户输入的文本把类名、方法名做成静态列表然后做前缀匹配。这种方案在简单场景下能跑但一旦用户输出了多行代码、改变了变量的类型提示列表就完全失去上下文关联属于典型的“黑匣子式”实现——看着能用一深入就翻车。真正可用的是基于语义模型的补全。Roslyn拿到用户输入文本后先解析成SyntaxTree再通过Compilation对象获取SemanticModel最后调用GetCompletionItemsAsync拿到当前光标位置的候选成员。这套链路能做到随输入实时刷新且严格基于当前代码上下文。最直接的差异同样是输入myList.静态扫描只能列出泛型List的常见方法语义补全能根据myList的实际声明类型列出Add、Remove、Where等精确成员连扩展方法都能带出来。2.3 框架约束.NET 4.0到底卡住了什么.NET 4.0的约束要掰开看。首先它默认没有Microsoft.CodeAnalysis程序集需要手动引用NuGet包其次很多Roslyn新版本在启动时会校验运行框架版本低于4.6.1的直接拒绝加载。常见的报错是“此实现不是Windows平台FIPS验证的加密算法的一部分”这类系统性异常或者直接抛BadImageFormatException。这套源码的做法是把Roslyn包锁在支持net40的旧版本比如1.3.x系列同时加上app.config里的bindingRedirect强制运行时加载指定版本。如果你拿到源码后直接升级了Roslyn包而没注意net40支持大概率第一步就启动失败。3. 用Roslyn在.NET 4.0里搭最小编辑器源码结构与关键类3.1 最小编译执行链路从字符串到程序集先写一个最小可用的运行时编译执行代码这是整个脚本编辑器的地基。以下是我常用的模板直接基于Roslyn的CSharpCompilationusing Microsoft.CodeAnalysis; using Microsoft.CodeAnalysis.CSharp; using Microsoft.CodeAnalysis.Emit; using System; using System.Collections.Generic; using System.IO; using System.Reflection; public class ScriptRunner { private readonly ListMetadataReference _references new ListMetadataReference(); public ScriptRunner() { // 必须引用当前运行时所在的程序集否则脚本里用不了System命名空间 _references.Add(MetadataReference.CreateFromFile(typeof(object).Assembly.Location)); _references.Add(MetadataReference.CreateFromFile(typeof(Enumerable).Assembly.Location)); // 如果你的宿主程序集有公开类型要暴露给脚本把宿主自身也加上 _references.Add(MetadataReference.CreateFromFile(Assembly.GetExecutingAssembly().Location)); } public object Run(string code, string entryMethodName Main) { var syntaxTree CSharpSyntaxTree.ParseText(code); var compilation CSharpCompilation.Create( DynamicScript Guid.NewGuid().ToString(N), new[] { syntaxTree }, _references, new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary)); using (var ms new MemoryStream()) { EmitResult result compilation.Emit(ms); if (!result.Success) { // 把诊断信息拼成可读文本抛给上层显示 throw new InvalidOperationException(string.Join(Environment.NewLine, result.Diagnostics)); } ms.Seek(0, SeekOrigin.Begin); var assembly Assembly.Load(ms.ToArray()); var type assembly.GetType(ScriptProgram); var method type.GetMethod(entryMethodName, BindingFlags.Public | BindingFlags.Static); return method?.Invoke(null, null); } } }逻辑说明这段代码做的事情是把一段C#源码解析成语法树然后CSharpCompilation.Create创建一个编译单元。注意参数里的OutputKind.DynamicallyLinkedLibrary它表示产物是DLL而不是可执行文件这样即使脚本里没有Main方法也能编译成功。Emit结果被写进内存流再用Assembly.Load加载到当前AppDomain最后通过反射找到入口方法并调用。参数说明里最需要注意的是_references列表脚本能用哪些类型完全由它决定。如果你漏了System.Core.dll即typeof(Enumerable).Assembly.Location那句using System.Linq在编译期就会报错。建议是把宿主程序集、核心运行时程序集、脚本可能用到的第三方程序集全部提前加进来。如果你的宿主是WinForms项目还需要拿typeof(Form).Assembly.Location引进来否则脚本里处理UI会直接编译失败。3.2 编辑器界面的核心类划分这套源码的编辑器部分不是用RichTextBox硬写的而是基于一个轻量级语法高亮控件常见做法是封装TextBoxBase或Scintilla的.NET包装承载编辑区再叠加一个列表控件展示补全项。源码中的核心类通常有这么几个ScriptEditorControl负责文本输入、光标位置跟踪、快捷键处理比如CtrlSpace触发补全。CompletionManager调用Roslyn的语义分析返回补全列表并管理补全窗口的显示位置。CompileService把编辑器里的全文喂给ScriptRunner返回编译结果或错误信息。ErrorMarker把编译诊断映射到编辑器的行号上画红色波浪线。我一般会把CompletionManager设计成事件驱动当文本内容变化且光标停留超过200毫秒就异步触发补全请求。避免每次击键都同步分析否则用户打字会出现明显的卡顿感。补全窗口的坐标计算要基于GetPositionFromCharIndex否则在滚动状态下会错位这个小细节经常被忽略。3.3 配置中心.NET 4.0下的依赖注入与初始化顺序初始化顺序在这套源码里是能跑和不能跑的分水岭。必须先初始化AdhocWorkspace和MetadataReference集合再创建Document最后建立语义模型。常见错误是把Document的创建放在引用之前导致后续GetSemanticModelAsync永远返回空。建议在Form_Load里按这样的顺序执行private AdhocWorkspace _workspace; private Document _document; private void InitScriptEngine() { // 1. 先建workspace它是Roslyn管理文档列表的容器 _workspace new AdhocWorkspace(); // 2. 准备引用包含脚本需要的基础程序集 var references new ListMetadataReference { MetadataReference.CreateFromFile(typeof(object).Assembly.Location), MetadataReference.CreateFromFile(typeof(Enumerable).Assembly.Location), MetadataReference.CreateFromFile(typeof(Form).Assembly.Location) }; // 3. 创建Project和Document指定语言为C#并带上引用 var projectInfo ProjectInfo.Create( ProjectId.CreateNewId(), VersionStamp.Default, ScriptProject, ScriptProject, LanguageNames.CSharp, compilationOptions: new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary), metadataReferences: references); var project _workspace.AddProject(projectInfo); _document _workspace.AddDocument(project.Id, Script.cs, SourceText.From()); }这段初始化代码的一个小技巧是先用空字符串建立Document后续每次文本变化时再不重建文档而是用_document.WithText(SourceText.From(newText))替换文本内容。这样能保持DocumentId稳定CompletionManager里持有的语义模型缓存不会失效。4. 智能提示的核心从语法树到补全列表的完整链路4.1 获取补全项的API调用GetCompletionsAsync的完整用法补全列表的生成走的是Roslyn的CompletionService。核心过程分三步拿到当前Document计算光标位置对应的Document位置注意文本变化后位置要同步更新然后调用GetCompletionsAsync获取候选。完整代码我拆解如下using Microsoft.CodeAnalysis.Completion; using System.Linq; using System.Threading.Tasks; public async TaskListstring GetCompletingItems(int cursorPosition) { // 确保Document是最新文本这一步不能省 var latestDoc _document.WithText(SourceText.From(_editorControl.Text)); // 获取CompletionService实例Roslyn的入口点 var completionService CompletionService.GetService(latestDoc); // 计算补全触发条件如果光标前面紧跟字母或点号才显示列表 if (!completionService.ShouldTriggerCompletion(SourceText.From(_editorControl.Text), cursorPosition)) { return new Liststring(); } var completionList await completionService.GetCompletionsAsync(latestDoc, cursorPosition); // 过滤掉不显示的项比如仅编译器使用的符号 var items completionList.Items .Where(i i.DisplayText ! await || i.DisplayText ! var) .Select(i i.DisplayText) .ToList(); return items; }这个方法的执行时机是文本变化事件和CtrlSpace快捷键。ShouldTriggerCompletion这一步是一个容易被忽略的细节如果用户输入的是字母系统会持续触发补全如果输入的是数字或括号结尾通常不该弹补全窗口这个判断能减少大量无效计算。一个实际体验优化如果补全列表有多页或者列表较长建议在返回列表前先按DisplayText去重因为Roslyn有时会把同一个符号以不同kind返回两次直接展示会让用户觉得列出了重复项。4.2 补全列表的数据绑定与高亮匹配逻辑拿到列表还不够要把列表显示在编辑器旁边并做关键词高亮。这块源码里常见的是重写了一个ListBox的DrawItem事件private void completionListBox_DrawItem(object sender, DrawItemEventArgs e) { if (e.Index 0) return; string displayText completionListBox.Items[e.Index].ToString(); string userInput _currentPrefix; // 当前用户已输入的前缀 e.DrawBackground(); if (userInput.Length 0 displayText.StartsWith(userInput, StringComparison.OrdinalIgnoreCase)) { // 把前缀部分画成蓝色加粗 using (var boldFont new Font(e.Font, FontStyle.Bold)) using (var blueBrush new SolidBrush(Color.FromArgb(0, 120, 215))) { e.Graphics.DrawString(displayText, boldFont, blueBrush, e.Bounds.Left, e.Bounds.Top); } } else { e.Graphics.DrawString(displayText, e.Font, new SolidBrush(SystemColors.WindowText), e.Bounds.Left, e.Bounds.Top); } e.DrawFocusRectangle(); }这段代码实现的是“前缀匹配高亮”即用户输入的字符在补全项里以蓝色粗体标出。这里有个坑如果你用StartsWith做过滤那么像“GetData”这样的项在用户输入“Data”时永远不会出现。更好的做法是同时支持Contains匹配子串匹配或者干脆交给Roslyn的CompletionFilterReason来判断。在源码里过滤规则通常是CompletionFilterReason.Type、CompletionFilterReason.Member这些枚举的组合只过滤掉不合理项让匹配交给显示层。4.3 参数列表的显示两个边界的取舍除了成员名补全智能提示还包括参数列表提示用户输入方法名后显示形参类型和名称。Roslyn的GetSymbolsAsync接口可以拿到当前方法重载列表var symbol await completionService.GetSymbolAsync(latestDoc, cursorPosition, item); if (symbol is IMethodSymbol methodSymbol) { foreach (var parameter in methodSymbol.Parameters) { string paramText ${parameter.Type.ToDisplayString()} {parameter.Name}; // 展示到参数提示框中 } }这个方法看起来很顺但有一个实际体验问题参数提示框的显隐时机很难拿捏。显示太早会遮挡代码显示太晚用户已经输入了一半参数。我自己的做法是只监控逗号和左括号两个字符当用户输入左括号时弹出提示输入对应右括号时隐藏。不要尝试实时更新参数高亮和“当前参数”位置因为光标在参数内的移动判定逻辑复杂且容易出Bug。参数提示做到“显示形参列表”这个粒度就足够了。5. 避坑.NET 4.0下的Roslyn版本、缓存和内存泄漏排错5.1 现象启动报错BadImageFormatException或直接崩溃原因引用了新版Roslyn的NuGet包但目标框架是.NET 4.0运行时无法加载编译目标为.NET 4.7.2的程序集。解决方法是把包版本降级到1.3.1或更高但仍在net40支持范围内的版本并在web.config或app.config里加好绑定重定向。具体操作为项目配置文件里添加dependentAssembly assemblyIdentity nameMicrosoft.CodeAnalysis.CSharp publicKeyToken31bf3856ad364e35 cultureneutral / bindingRedirect oldVersion0.0.0.0-1.3.1.0 newVersion1.3.1.0 / /dependentAssembly5.2 现象补全列表一直空白GetCompletionsAsync返回空集原因常见有两种一是Document的文本不是最新内容光标位置和文本行数对应不上因为用户删除了某行导致位置偏移二是MetadataReference缺少关键程序集比如没加System.Runtime。解决方法是每次触发补全前先检查_document.GetTextAsync().Result.ToString()与编辑框当前文本是否一致不一致就先用WithText覆盖再计算位置。另一个排查点如果项目里同时存在多个版本的RoslynCompletionService.GetService拿到的实例可能是旧版的需要检查是否有程序集冲突。5.3 现象编译成功后脚本执行却找不到类型原因脚本源码里的类名和ScriptRunner里的固定类名不匹配。比如Run方法里查找“ScriptProgram”但用户写的类叫“MyProgram”。解决方式是把入口方法名和类名做成参数传入或者在编译前用SyntaxTree.GetRoot()的DescendantNodes()分析出所有的类声明让运行器自动选择包含入口方法的类型var root syntaxTree.GetRoot(); var classDecl root.DescendantNodes() .OfTypeClassDeclarationSyntax() .FirstOrDefault(c c.Identifier.ValueText.Contains(Script));这里取FirstOrDefault的自适应逻辑是一个稳妥兜底方案只要类名里包含“Script”字样就能命中完全避免用户改类名导致宿主反射失败。5.4 现象编辑器使用久了内存暴涨原因每次文本变化都新建Document和Compilation旧对象没有释放尤其是GetCompletionsAsync每次返回后CompletionList里的符号列表会持有大量ITypeSymbol引用。解决方式是全局只保留一个AdhocWorkspace文本变化时复用同一个DocumentId补全完成后立即将completionList置空并调用GC.Collect在空闲时。另一个常用的优化是只在光标停留超过300毫秒才触发语义分析避免连续击键时产生大量垃圾。6. 把编辑器接到你的业务里宿主调用、权限沙箱与性能调优6.1 脚本与宿主的类型交互暴露对象给脚本调用编辑器本身只是输入工具真正的价值是让脚本调用宿主业务逻辑。为了实现“脚本里能操作主程序的对象”需要把宿主实例作为全局变量传给脚本。常见做法是创建一个ScriptGlobals类通过修改CSharpCompilationOptions的ScriptClassName特性实现或者更直接地把脚本源码做字符串拼接在用户代码前面插入一行dynamic host null;然后运行时给脚本注入宿主引用。但Runtime中更推荐用“静态实例”方案在ScriptRunner中定义一个静态字段存放宿主上下文脚本通过HostContext.Instance访问。这个方案避免了在脚本顶部拼接代码带来的语法压力也方便后续加权限控制。6.2 安全边界不允许脚本碰文件系统和网络脚本编辑器一旦暴露给用户就相当于在程序里开了后门。即使是在公司内部的上位机工具里也要做沙箱。最简单的分层隔离是限制引用的程序集——_references里不包含System.IO.FileSystem和System.Net.Http脚本自然用不了文件读写和网络请求。如果你的脚本确实需要访问某些文件不要直接给File类而是通过宿主提供白名单方法比如HostContext.Instance.LoadConfig(string filePath)在方法内部校验路径是否处于允许目录。另一个思路是用AppDomain隔离把脚本跑在单独的AppDomain里并配合PermissionSet避免脚本恶意调用Environment.Exit把宿主进程一起结束。6.3 性能调优异步编译与缓存解析结果脚本编译是一个耗时操作如果用户在编辑器里敲击频繁不能每次都重新编译整个程序集。常见做法是“编辑时只做语法检查和语义高亮”这部分Roslyn有增量缓存只有点击“运行”按钮时才走完整编译链路。我在实际项目里会再加一层“代码片段模板”机制如果编辑器里只有一行表达式比如DateTime.Now.ToString(yyyy-MM-dd)则走轻量级表达式编译不生成完整程序集。做法是判断当前文本是否包含类声明或方法声明如果没有就用CSharpScript.EvaluateAsyncRoslyn的脚本API注意它同样有net40版本兼容问题直接执行表达式并返回结果。6.4 验证补全效果的几条基准测试做完了脚本编辑器怎么证明智能提示是“真智能”而不是“碰巧能用”我一般跑四组验证用例。第一组声明一个Listint输入list.后确认补全项包含Add、Where、Select且不包含Split这类字符串方法。第二组在类里写一个私有方法输入方法名前两个字母确认私有成员能出现在补全列表。第三组输入System.确认命名空间下的类型出现在提示中。第四组故意输入一个错误类型名确认补全结果为空且编译错误能正确标记。这四组覆盖了成员补全、私有成员可见性、命名空间递归和错误处理四个维度过不了任何一组说明语义模型链路还有断点。最后说一句自己的习惯我每次拿到别人的脚本编辑器源码第一件事不是打开界面看效果而是先查它的Roslyn引用版本和初始化顺序因为大部分翻车都出在这两处。这个项目能做到在.NET 4.0上带智能提示地把脚本运行起来整个方案的工程取舍是经得起推敲的值得你花一个下午把源码跑通并接到自己的上位机或自动化工具里。希望帮到你。本文还有配套的精品资源点击获取