基于Roslyn与AvalonEdit构建C#代码编辑器：动态编译与智能提示实战-北京尧图网络

简介面向.NET开发者的编辑器功能整合资源以AvalonEdit实现文本编辑、复制粘贴、撤销重做等基础交互以NRefactory提供自动补全与成员提示以Roslyn完成跨Framework与NetCore的动态编译解决传统编译器仅在旧框架下可用的问题。资源压缩包仅十三点六九兆字节包含六百二十个文件以二百七十一个C#源码文件为主体另有八十九个动态链接库、二十二个语法高亮定义文件、若干界面布局与工程配置文件便于直接还原工程结构并理解模块分工。目前已有七百四十六人学习适合具备一定基础并期望深入编辑器二次开发的程序员。资源内不仅涵盖编辑器的完整实现链路还展示了NRefactory与Roslyn之间的协作方式从词法分析到编译执行均有对应源码可查。通过阅读源码和配置文件能够掌握如何将代码提示窗口嵌入编辑器以及如何在NetCore项目中注册Roslyn服务对构建类似集成开发环境的轻量工具很有参考价值。1. 这个项目能干什么一个能跑C#代码的轻量编辑器有段时间我在写技术文档经常要在文章里贴一段可运行的C#代码验证完再发出去。打开Visual Studio创建一个临时控制台工程太笨重线上编辑器跟本地运行时又总有差异。后来我干脆用三个库拼了一个迷你IDEAvalonEdit负责文本编辑NRefactory负责把光标处的代码解析成语法树并给出智能提示Roslyn在后台线程里完成动态编译再把输出拉回面板。写代码、出提示、点运行、看结果整个闭环都在同一个WPF窗口内完成。适合做代码片段验证工具、C#教学演示白板或者给内部管理系统注入一段可编译执行的脚本。如果你关注Roslyn动态编译或者在NetCore下想集成一款文本编辑器这个项目能给你一套完整可跑的参考实现而不是零散的三段示例代码。2. 整体架构与项目结构三个库怎么在进程里各司其职2.1 技术选型为什么偏偏是这三块先说文本编辑器。AvalonEdit是WPF生态里最成熟的源码编辑器控件它把行高亮、语法高亮、代码折叠都建立在虚拟化渲染之上几十万行的文档滚动起来也不卡。相比之下RichTextBox带着OLE和富文本的负担做代码编辑反而拖沓。AvalonEdit的输出对象是普通字符串和TextDocument跟解析器和编译器交互都方便。再说代码提示。很多人会直接跳过NRefactory去用Roslyn做自动完成但那是把简单问题复杂化了。Roslyn的Workspace体系服务于整个解决方案级别的IDE要为一句补全搭出Document和Project成本太高。NRefactory的CSharpParser从源码字符串出发一次解析就能拿到语法树再遍历TypeDeclaration和MemberDeclaration就能猜出成员名称虽然它没有语义模型但对提示这个场景足够用。最后是动态编译。Roslyn是C#编译器本身的对外开放层CSharpCompilation接收语法树和程序集引用能直接把源码变成程序集字节流再通过Assembly.Load装入当前进程执行。它跟.NET Core运行时天然同源不需要启动外部编译器进程也不依赖临时文件正好补上AvalonEdit和NRefactory不涉及的“运行”环节。2.2 项目目录结构我的实现里把代码按职责拆成了三个服务类这样编辑器UI和编译逻辑能彻底解耦CSharpPad/ ├─ App.xaml ├─ MainWindow.xaml ├─ MainWindow.xaml.cs ├─ Services/ │ ├─ CompilerService.cs // Roslyn编译与执行入口 │ ├─ CompletionProvider.cs // NRefactory语法树解析与提示生成 │ └─ HighlightingSetup.cs // AvalonEdit高亮与字体初始化 ├─ Models/ │ └─ CodeOutput.cs // 输出模型文本、时间戳、是否异常 └─ CSharpPad.csprojMainWindow.xaml里放了一个TextEditor和一个运行按钮底部用ListBox展示编译诊断和运行输出。代码补全窗口挂在TextEntered事件上不写进主窗体逻辑。Models里的CodeOutput用于把编译错误和运行时异常统一成一个个展示项避免字符串拼接导致格式乱掉。2.3 环境准备创建项目并安装NuGet包先用dotnet命令行创建WPF工程dotnet new wpf -n CSharpPad -f net6.0 cd CSharpPad dotnet add package ICSharpCode.AvalonEdit dotnet add package ICSharpCode.NRefactory dotnet add package Microsoft.CodeAnalysis.CSharp我选net6.0因为它是长期支持轨道三个库的兼容性在这个目标框架下都验证过。如果你直接上.NET 8AvalonEdit的运行时行为会有些变化具体在避坑章节讲。NRefactory比较特殊它还是netstandard2.0的产物但net6.0完全能引用只是要注意它不支持新版C#语法这会在集成时反复被提醒。2.4 启动初始化与事件绑定在MainWindow构造函数里我先配置AvalonEdit的显示参数再挂上文本变更事件和运行按钮回调public MainWindow() { InitializeComponent(); editor new TextEditor(); editor.SyntaxHighlighting HighlightingManager.Instance.GetDefinition(C#); editor.ShowLineNumbers true; editor.FontFamily new FontFamily(Consolas); editor.FontSize 14; editor.TextChanged OnTextChanged; runButton.Click OnRunClicked; editorGrid.Children.Add(editor); } private void OnTextChanged(object sender, EventArgs e) { // 每次文本变化后延迟触发NRefactory解析 // 避免用户每敲一个字符就解析一整份代码 }SyntaxHighlighting决定关键字、字符串、注释的颜色ShowLineNumbers显示左侧行号。FontFamily和FontSize会影响文本度量也直接关系到后续CompletionWindow弹出时候选列表跟光标的对齐位置。之所以把提示和编译拆成两个Service是因为两者都可以放到后台线程只有UI更新必须在主线程。CompletionProvider不持有任何控件引用CompilerService也只处理字符串和程序集这样后续要换成脚本执行引擎或者把AvalonEdit换成别的控件都只需要替换对应服务。3. 核心模块拆解从字符输入到智能提示的完整链路3.1 初始化AvalonEdit编辑器AvalonEdit的TextEditor在界面上就是一个普通控件但它的内部构造比普通TextBox复杂很多。需要自己管理缩进策略、折叠策略和高亮规则。初始化代码我放在HighlightingSetup里public static TextEditor Create() { var editor new TextEditor(); editor.SyntaxHighlighting HighlightingManager.Instance.GetDefinition(C#); editor.ShowLineNumbers true; editor.TextArea.IndentationStrategy new CSharpIndentationStrategy(editor.Options); editor.Options.IndentationSize 4; editor.Options.ConvertTabsToSpaces true; editor.Options.HighlightCurrentLine true; return editor; }CSharpIndentationStrategy是AvalonEdit自带的C#缩进策略输入花括号后回车会自动换行并缩进到正确位置。IndentationSize4是行业常用宽度ConvertTabsToSpaces会阻止制表符在不同显示环境下错位。HighlightCurrentLine会在光标所在行绘制背景色长代码里找光标位置很管用。如果你不希望语法高亮过多干扰自定义主题可以不用GetDefinition而是实现自己的IHighlightingDefinition但那样就要自己定义关键字表、注释规则和字符串规则工作量会翻倍。3.2 用NRefactory解析代码NRefactory的核心入口是CSharpParser。它是一个低层级解析器输入源码字符串输出SyntaxTree。我的CompletionProvider用一段很短的代码完成解析和候选提取public static Liststring GetMembers(string sourceCode, int caretOffset) { var parser new CSharpParser(); var syntaxTree parser.Parse(sourceCode, User.cs); // 找到当前代码里的类型声明 var declarations syntaxTree.Descendants .OfTypeICSharpCode.NRefactory.CSharp.TypeDeclaration() .ToList(); var names new Liststring(); foreach (var td in declarations) { names.Add(td.Name); foreach (var member in td.Members) { if (member is MemberDeclaration md md.Name ! null) { names.Add(md.Name); } } } return names; }parser.Parse方法会解析整份代码并生成语法树第二个参数是文件名主要用于错误报告。Descendants返回的是一个延迟执行的迭代序列只有真正枚举时才会遍历子节点。OfType ()过滤出class、struct、enum等类型定义td.Members则包含字段、属性、方法定义。这是一种纯语法层面的枚举它不会检查成员是否有访问权限、是否重复定义但用来做补全候选已经够用。不过NRefactory最麻烦的一点是它只处理C# 6.0以前的语法。如果我的编辑器里写了record定义、is not模式匹配parser.Parse会直接把这些节点标记为未知节点后续遍历时可能抛出异常。所以我每次调用GetMembers前都会做一层try/catch异常时降级成一个简单的正则扫描只提取public/static关键词后面的单词。这个降级逻辑保证了编辑器不至于因为一段现代语法就彻底崩溃。3.3 在光标处弹出自动完成列表AvalonEdit里做自动完成的标准方式是CompletionWindow。这个窗口会监听键盘方向键回车或双击确认候选。我把入口挂在TextEntered事件上只检测用户输入小数点private CompletionWindow _completionWindow; private void EditorTextEntered(object sender, TextCompositionEventArgs e) { if (e.Text ! .) return; var caretPos editor.CaretOffset; var source editor.Text; Task.Run(() { var candidates CompletionProvider.GetMembers(source, caretPos); Dispatcher.Invoke(() { if (_completionWindow ! null) _completionWindow.Close(); _completionWindow new CompletionWindow(editor.TextArea); foreach (var c in candidates) { _completionWindow.CompletionList.CompletionData.Add( new SimpleCompletionData(c, 成员提示)); } _completionWindow.Show(); }); }); }这里把NRefactory的解析放到了Task.Run后台线程避免解析阻塞UI。AvalonEdit的CompletionWindow在同一时间只能存在一个实例所以每次打开新窗之前必须Close掉旧的。CompletionList.CompletionData是一个集合添加实现ICompletionData接口的对象。我的SimpleCompletionData长这样public class SimpleCompletionData : ICompletionData { public SimpleCompletionData(string text, string description) { Text text; Description description; } public object Description { get; set; } public string Text { get; } public double Priority 1; public ImageSource Image null; public void Complete(TextArea textArea, ISegment completionSegment, EventArgs insertionRequestEventArgs) { textArea.Document.Replace(completionSegment, Text); } }ICompletionData是AvalonEdit定义的补全候选接口。Complete方法负责把选中的Text插入文档completionSegment是触发补全时已经存在的输入段比如用户输入了“str”补全“string”时会自动替换掉那三个字符。Priority字段控制排序权重数值越大越靠前我这里统一返回1后续可以按调用频率调整。Image返回null如果你有图标资源可以在类型成员前面加上不同类型的小图标视觉上会专业很多。4. 核心模块拆解Roslyn动态编译从源码到可执行程序集4.1 构建CSharpCompilation编译单元Roslyn动态编译对初学者来说像个黑匣子语法树、MetadataReference、EmitResult概念一大堆。其实它的核心链路就三步解析源码、创建编译对象、执行Emit输出程序集。我写的CompilerService把这三步封装成一个静态方法public static Assembly Compile(string code) { var tree CSharpSyntaxTree.ParseText(code, new CSharpParseOptions(LanguageVersion.Latest)); var references GetReferences(); var compilation CSharpCompilation.Create( DynamicAssembly, new[] { tree }, references, new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary)); using var ms new MemoryStream(); var emitResult compilation.Emit(ms); if (!emitResult.Success) { var errors emitResult.Diagnostics .Where(d d.Severity DiagnosticSeverity.Error) .Select(d d.ToString()); throw new CompilationException(string.Join(\n, errors)); } ms.Seek(0, SeekOrigin.Begin); return Assembly.Load(ms.ToArray()); }CSharpParseOptions的LanguageVersion.Latest表示用当前Roslyn支持的最新C#版本这意味着代码里可以写record、init、primary constructor等新语法。OutputKind.DynamicallyLinkedLibrary决定编译成DLL而不是EXE这样Assembly.Load之后用反射就能拿到任意类型也不要求被编译代码必须有Main方法。Emit方法会把结果写入MemoryStreamEmitResult.Success是判断编译是否成功的唯一标准。失败时Diagnostics里会含错误、警告、信息三级消息我这里只取Error级别再转成字符串拼成异常信息。4.2 准备元数据引用动态编译的程序集必须引用它依赖的运行时程序集否则会报“找不到System.Object”或“已知程序集引用不足”的错误。这是Roslyn和普通csc编译最不一样的环节。我收集引用的方式如下private static ListMetadataReference GetReferences() { var tpa ((string)AppContext.GetData(TRUSTED_PLATFORM_ASSEMBLIES)) .Split(Path.PathSeparator) .Where(p !string.IsNullOrEmpty(p) File.Exists(p)) .ToList(); return tpa .Select(a MetadataReference.CreateFromFile(a)) .CastMetadataReference() .ToList(); }TRUSTED_PLATFORM_ASSEMBLIES是.NET Core运行时提供的环境变量值是一个用路径分隔符分割的字符串包含了进程启动时加载的全部核心程序集路径。这个列表里有System.Runtime、System.Console、System.Linq等覆盖大部分用户代码的依赖需求。MetadataReference.CreateFromFile会读取程序集的元数据生成引用对象注意要过滤空路径和不存在的文件否则Emit阶段会抛出异常。4.3 执行编译后的代码得到Assembly之后用反射找到入口点并执行public static string Run(Assembly assembly) { var type assembly.GetType(Program); if (type null) return 未找到Program类型; var main type.GetMethod(Main, BindingFlags.Public | BindingFlags.Static); if (main null) return 未找到Main方法; var parameterInfos main.GetParameters(); var args parameterInfos.Length 0 ? null : new object[] { new string[] { } }; try { var result main.Invoke(null, args); return result?.ToString() ?? 执行完成; } catch (TargetInvocationException ex) { return $运行时异常: {ex.InnerException?.Message}; } }Main方法可能有无参和带string[]两种形式所以调用前要检查参数个数。反射调用静态方法用null作为实例参数。如果用户代码里抛出异常比如空引用或者除零Invoke会把它包装成TargetInvocationException真正的问题在InnerException里。这里直接返回InnerException.Message能帮助用户快速定位错误。4.4 把编译和执行串成一条链路在MainWindow里点运行按钮时完整调用是这样的private void OnRunClicked(object sender, RoutedEventArgs e) { var code editor.Text; Task.Run(() { try { var asm CompilerService.Compile(code); var output CompilerService.Run(asm); Dispatcher.Invoke(() outputListBox.Items.Add(output)); } catch (CompilationException ex) { Dispatcher.Invoke(() outputListBox.Items.Add(ex.Message)); } }); }编译和反射执行都是CPU密集操作放在后台线程可以避免界面卡死。如果编译失败捕获CompilationException并把错误信息加入输出列表。注意Assembly.Load会把程序集载入默认上下文重复编译同一个类名会导致冲突甚至类型加载失败这点我在避坑章节专门讲。5. 避坑与排查三块拼图拼接现场的血泪经验5.1 高DPI下编辑器文字发虚现象程序在4K屏或者笔记本缩放125%的环境下运行AvalonEdit的字体明显模糊行号跟文本内容还对不齐。原因WPF默认按系统DPI进行缩放渲染但AvalonEdit内部的文本层有自己的视觉树缩放后如果没有开启像素对齐就会出现半个像素偏移最终展示出来的效果就是发虚。解决在App启动时做DPI声明然后给TextEditor开启布局对齐。代码上我是这样处理的// App.xaml.cs protected override void OnStartup(StartupEventArgs e) { base.OnStartup(e); TextOptions.TextFormattingModeProperty.OverrideMetadata( typeof(TextEditor), new FrameworkPropertyMetadata(TextFormattingMode.Display)); }TextFormattingMode.Display会让WPF优先用显示器物理像素对齐字形文本会更锐利。同时给TextEditor设置FontSize为整数比如14而不是14.5避免子像素间距计算。这个坑在普通Win32程序上不明显但WPF里几乎必现尤其笔记本外接屏幕切换缩放比例的时候玄学感很强。5.2 NRefactory不认新式C#语法现象编辑器里输入record定义或者is not模式匹配NRefactory的parser.Parse正常返回但遍历Descendants取成员时直接抛NotSupportedException或者返回的成员列表是空的。原因NRefactory的语法解析能力停留在C# 6.0遇到现代语法节点不知道怎么分类很多新节点被标记成UnknownNode后续查询成员时就会翻车。解决我在CompletionProvider的外层加了异常捕获同时检测到语法树里存在UnknownNode时就自动降级成正则扫描。降级代码很粗糙但稳定private static Liststring ExtractByRegex(string source) { var matches Regex.Matches(source, \b(public|private|protected|internal)\s(static\s)?[\w\[\]]\s(\w)\(); return matches.CastMatch() .Select(m m.Groups[3].Value) .Distinct() .ToList(); }这段正则只匹配“访问修饰符返回类型方法名(”形式的方法定义用于补全的候选已经够用。如果项目必须完整支持C# 10的提示终极解法是放弃NRefactory直接改用Roslyn的语法树和语义模型代价是代码量增加一半。5.3 Roslyn引用集合不全导致编译失败现象动态编译时最常见报错是CS0246“找不到类型或命名空间名称Object”或者CS1703“已找到具有相同标识符的程序集”。原因编译单元没有包含运行时依赖的元数据引用。我第一次实现时只引用了typeof(object).Assembly.Location结果编译出来的DLL在加载时因为缺少System.Runtime直接崩掉。解决用TRUSTED_PLATFORM_ASSEMBLIES枚举运行时所有受信任程序集路径逐个转成MetadataReference。补充一个排查技巧Emit失败时先在Diagnostics里打印所有Error不要只打印Description。Diagnostic.ToString()会包含错误码、文件位置、行列号比Description信息完整得多。我还遇到过重复引用同一个程序集导致CS1703去重逻辑要加在Select之前用HashSet包一下路径。5.4 后台线程更新UI导致跨线程异常现象编译线程执行完调用outputListBox.Items.Add时抛出InvalidOperationException提示调用线程无法访问此对象因为它不是创建它的线程。原因WPF的UI元素只能在Dispatcher线程访问Task.Run里的代码运行在线程池自然没有权限操作ListBox。解决所有UI更新都要通过Dispatcher.Invoke。我在第四节代码里已经用Dispatcher.Invoke包装了输出写入但这还不够。如果编译线程里连续多次Invoke会把主线程消息队列塞满造成界面假死。我一般会把多次输出聚合到一个集合里一次性Invoke再循环Add。另外要小心在Invoke的委托里访问编辑器Text属性因为用户可能正在输入最好先快照一份代码字符串再传给后台线程。5.5 内存泄漏重复编译导致程序集无法卸载现象连续点运行按钮几十次任务管理器里内存稳步上升Assembly列表越来越长GC也回收不掉。原因程序集默认加载到AssemblyLoadContext.Default这是进程级的默认上下文一旦加载就不能卸载除非整个进程退出。解决如果你的工具只是半天用一下可以忽略。但长期运行时必须使用可卸载的AssemblyLoadContextpublic class CollectibleAssemblyLoadContext : AssemblyLoadContext { public CollectibleAssemblyLoadContext() : base(isCollectible: true) { } protected override Assembly Load(AssemblyName assemblyName) null; }使用后调用context.Unload()和GC.Collect()触发卸载。注意两个坑一是Unload必须在非目标程序集线程调用二是编译产生的Assembly实例不能在这个上下文外被引用否则卸载失败。踩过这个坑后我再也不敢把需要长期运行的工具跟编译器程序集放在同一个默认上下文里了。6. 二次开发把迷你编辑器改造成趁手的代码工具6.1 加入代码格式化NRefactory自带CSharpFormatter可以直接格式化源码。但前面说了它对现代语法支持有限所以我在改造时只用Roslyn的SyntaxNode做少量结构调整。更实用的做法是给编辑器加一个“格式化”快捷键调用AvalonEdit的TextDocument.Replace把整个文档替换成格式化后的结果。这一步建议放到后台线程因为格式化超大文档时也会卡UI。6.2 升级提示引擎从NRefactory迁到Roslyn既然编译已经用了Roslyn提示引擎完全可以逐步迁移。Roslyn的SyntaxTree和SemanticModel组合起来能拿到成员的确切类型和继承关系。迁移步骤是把CompletionProvider的输入参数从字符串变成字符串加光标位置然后用CSharpSyntaxTree.ParseText生成语法树再通过Compilation.GetSemanticModel获取语义模型。拿到SemanticModel之后用GetSymbolInfo查询光标处的符号遍历它的属性和方法提示自然就准确了。这个改造会让提示从“列出所有成员”变成“列出当前变量真实拥有的成员”体验接近正式IDE。6.3 验证与调试改造后我习惯先写一个最小测试脚本不打开界面直接调用CompilerService编译几段代码以及调用新的CompletionProvider检查候选内容。因为服务和UI解耦这些测试能脱离WPF单独跑执行速度快出问题也好定位。这次把AvalonEdit、NRefactory、Roslyn三块拼在一起最大体会是这三件事之间没有现成的“标准接法”。补全窗口的弹出时机、语法树的解析边界、编译引用的收集方式每一层单独用都不难拼起来处处是接口摩擦。以前我总以为代码提示和编译是锦上添花的功能真正让编辑器能落地的是那些边角料一样的避坑经验。从那以后我每次做集成都会先在空房间里架一个最小可运行骨架把三块组件用最简单方式连起来确认编译通过后再逐步加功能。希望这些细节能帮到你也在你的编辑器项目里少走几个弯路。本文还有配套的精品资源点击获取

基于Roslyn与AvalonEdit构建C#代码编辑器：动态编译与智能提示实战

相关推荐

Ray分布式计算框架入门：核心原理解析与Python并行实践

大O表示法面试全攻略：从复杂度分析到数据结构性能优化

基于Django的服装品类趋势与消费者洞察可视化系统解析

更多资讯

SpringBoot+Vue实战：学校物资采购系统开发与部署记录

文件上传漏洞攻防全解析：从绕过原理到五层防护落地

XFS误删文件恢复实战：原理、工具与避坑指南

2025江苏省企业技术中心年度评价对象与材料提交全解析

【信息论】自信息信息熵｜事情越离谱，信息量越大？

推荐几本权威的钱币评级的学习书籍

今日更新

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？