C#经典编程200例：旧代码在.NET 8下的编译、改造与实战指南

简介《C#经典编程200例》是一套面向C#入门与进阶学习者的编程实例合集适合通过动手练习掌握从基础语法到项目开发的完整知识链。压缩包约41.25MB文件总数与类型明细暂未提供但不影响直接解压使用。目前已有289人学习下载。内容覆盖变量、运算符、流程控制等基础语法类与对象、接口、泛型等核心面向对象概念并延伸至异常处理、文件操作、网络编程、LINQ查询、异步编程、事件与委托等实用技术同时涉及Windows Forms、WPF、ASP.NET及单元测试等应用方向。每个实例围绕实际编程问题展开配有清晰的问题描述与实现思路能够帮助读者边练边学逐步建立代码调试与排错能力。对于希望系统提升C#实战水平、准备面试或完成课程作业的开发者这套200例素材可作为随身练习册反复演练以巩固知识并应对实际开发场景。1. 这本C#经典编程200例为什么老代码反而值得刷如果你手头的工作是维护一套跑了七八年的老系统翻开代码仓库那一刻大概率会撞见这样的写法DataTable 里逐行取数拼字符串、ArrayList 装着对象再强转、事件处理器里塞了三百行业务逻辑。这些代码和现在的 .NET 规范格格不入但系统稳定运行至今没人敢乱动。这时候你就明白C#经典编程200例这类习题集练出来的不是优雅语法而是读懂烂代码、改得动烂代码的底气。这本书在初学阶段的价值被严重低估了。它不像现代教程那样讲依赖注入、async/await、LINQ 表达式它用两百个短小精悍的例子把语言底子打牢类型转换、循环边界、字符串操作、文件读写、集合增删。这些恰恰是刷题网站和框架教程都不愿意细讲的部分。对两类人最有用一是刚学完语法、想用大量小练习巩固肌肉记忆的新手二是需要接手遗留系统、每天面对老式 C# 代码的开发者。我的建议很直接别管书龄多老买一本来用现代环境把每个例子亲手敲一遍收获比看十遍教程都大。2. 搭建重编译环境让旧示例在 .NET 8 下复活2.1 老代码为什么一跑就报错框架差异的三个断面那本两百例成书年代对应的技术栈通常是 .NET Framework 2.0 到 3.5C# 语言版本停留在 2.0 或 3.0。而你现在机器上大概率装的是 .NET 6 或 8语言版本已经到 C# 12。这不是简单的“升级一下项目文件”就能解决的事三个断面决定了你至少有一个下午要花在环境调试上。第一个断面是 API 移除与过时。老书里常见的HttpWebRequest写法在 .NET Core 之后仍然能用但被标记为过时更麻烦的是System.Drawing相关的绘图例子在非 Windows 平台上直接运行时行为完全不同。第二个断面是控制台编码。老代码直接Console.WriteLine(中文)在旧框架下输出正常在 .NET 8 的控制台里可能变成乱码这和 .NET Core 默认 UTF-8 编码策略有关。第三个断面是项目结构。 .NET Framework 时代一个 .csproj 文件里写死所有编译选项现在 SDK-style 项目用通配符自动包含文件配置方式完全不同。这意味着你不能天真地把书里的代码复制进新项目就指望跑通。我一般会先建一个统一的控制台项目再逐个章节把例子拆成独立方法用入口点转发调用。这样哪些例子能跑、哪些报错一目了然。2.2 最小化环境搭建从 SDK 到第一个编译通过先装 SDK推荐装 LTS 版本比如 .NET 8。装完验证命令然后新建一个控制台项目作为两百例的统一宿主dotnet --version mkdir CSharp200Examples cd CSharp200Examples dotnet new console -n CSharp200 -f net8.0 cd CSharp200创建完成后打开CSharp200.csproj会看到当前采用 SDK-style 格式默认包含了目录下所有 .cs 文件。这比老式项目手动逐个添加文件要省事得多。接着处理一个关键问题让老代码里的中文和编码行为可预期。我习惯在最开始就加几行using System.Text; // 让 Windows 控制台正确显示中文 Console.OutputEncoding Encoding.UTF8; Console.InputEncoding Encoding.UTF8;放在Program.cs的入口最前面。注意Console.OutputEncoding和Console.InputEncoding两个都要设置只设输出会导致从控制台读中文时出现奇怪字符。这个设置在 .NET 8 的 Windows 终端下表现稳定在老式 cmd 窗口下也基本兼容。接下来处理老代码中的中文读取问题。很多经典例子涉及读取本机文本文件并统计字符老书里默认文本文件是 ANSI/GB2312 编码而 .NET Core 默认只带 UTF-8 和 Unicode。解决方式是注册编码提供程序我给你一个完整的可运行片段using System; using System.Text; using System.IO; class Program { static void Main() { // 注册代码页编码提供程序GB2312、GBK 等老编码才可用 Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); string path C:\temp\example.txt; if (!File.Exists(path)) { File.WriteAllText(path, 你好世界, Encoding.UTF8); } // 以 GB2312 读取老式文本文件 string content File.ReadAllText(path, Encoding.GetEncoding(GB2312)); Console.WriteLine(content); } }这段代码里Encoding.RegisterProvider必须在使用任何非 Unicode 编码前调用。Encoding.GetEncoding(GB2312)在注册了 Provider 之后才能解析到正确代码页。File.ReadAllText的第二个参数指定读取编码缺省时 .NET 会尝试 BOM 检测没有 BOM 则默认 UTF-8这正是老文件乱码的根因。2.3 批量编译策略一个入口点调度两百个例子把两百个例题都塞进一个解决方案里逐个建项目会把自己累死而且编译速度慢得让人想放弃。我常用的做法是把书分成几个大块——语法基础、算法逻辑、字符串处理、文件操作、面向对象、界面相关。在宿主项目里按块建静态类每个例子对应一个静态方法入口点用switch或反射机制调用。using System; class Program { static void Main(string[] args) { if (args.Length 0) { Console.WriteLine(用法: dotnet run -- 章节id 例题id); Console.WriteLine(示例: dotnet run -- chapter3 15); return; } string chapter args[0]; int exampleId int.Parse(args[1]); switch (chapter) { case chapter3: Chapter3.RunExample(exampleId); break; case chapter4: Chapter4.RunExample(exampleId); break; default: Console.WriteLine($未知章节: {chapter}); break; } } }这种调度方式的好处是编译一次反复运行单个例题不必重启整个项目出错的例题能单独定位互不干扰。args[0]对应章节标识args[1]对应例题编号在Chapter3.RunExample内部再用嵌套 switch 分发。这里的参数设计完全是个人偏好你也可以改成枚举或字典映射但核心思路不变一个宿主项目管所有题而不是两百个项目各管各的。3. 拆解两百例的结构题型分布与现代视角下的取舍3.1 经典题型地图六类题目的训练侧重老式习题集不像现代在线题库那样按难度标签分类但页面上题目的排布是有内在逻辑的。按我自己的经验两百例大致可以分成六个阵营。第一类是语法基础题覆盖变量声明、类型转换、运算符优先级、分支与循环这部分大概占四分之一是整本书的地基。第二类是数组与集合操作包括一维二维数组的遍历、排序、插入删除。第三类是字符串与正则处理包括字符统计、子串查找、敏感词替换。第四类是文件与目录操作读写文本、遍历目录、复制移动。第五类是面向对象三大特性及接口、委托和事件这类题在两百例里开始变难也最接近真实项目。第六类是界面与绘图在老书里通常是最后几章但现在参考价值明显下降。这张题图决定了刷题顺序不要从第一页读到最后一页而是按专题横向打透。比如今天只做文件操作相关的十道题把所有读写、路径拼接、异常处理的套路都过一遍比一天刷三十道语法题有效得多。原因很简单语法题的重复度太高而文件操作这类涉及资源管理的题目边界情况多每一道都能暴露新的问题。3.2 哪些题至今有价值哪些可以跳过我的观点很明确算法和文件操作类题目完全不过时面向对象设计题要带着批判眼光做图形界面题直接跳过。这不代表界面题毫无意义只是当年那些控件拖拽、事件绑定的操作在现在的主流开发里已经被替代花时间重复没有回报。真正让我觉得宝刀不老的是字符串处理题。书里那些“统计一段英文里每个字母出现的次数”“判断一个字符串是否是回文”“提取所有邮箱地址”的题放到今天依然是面试常见的白板题原型。它们的共同点是不依赖任何框架特性纯粹考语言功底和逻辑思维这恰恰是最难被替代的能力。另一类被低估的是“内存中集合操作”的题目比如“把两个有序数组合并成一个有序数组”。这类题当年要求手写循环比较大小现在用 LINQ 一行搞定但我建议你仍然老实地用循环写一遍。原因和性能无关而是手写一遍你才能理解OrderBy背后做了什么。真实项目里遇到特殊排序规则时不会 LINQ 照样能写可依赖 LINQ 的人脱离了框架就手足无措。3.3 题型分布的隐形逻辑每章之间的依赖关系读这本两百例时一个容易被忽略的现象是前一章的例题会用到后一章才会正式讲解的特性。比如数组排序的题里可能提前出现Array.Sort虽然当时没讲过但答案是查出来的。这不是作者编排失误而是刻意的“预埋”。我建议按这个链路刷语法基础 → 字符串操作 → 数组与集合 → 文件与目录 → 面向对象 → 综合应用。中间任何一环没打通后面遇到相关例题会卡壳。特别是字符串和数组它们在文件操作题里是基础工具如果这两个板块没练熟做文件题时会同时面临语法和业务逻辑双重难题排错时很难定位是哪个环节出了问题。4. 三类高频题的现代改造从两百例到能跑的代码4.1 排序题老式冒泡 vs 现代泛型扩展排序题几乎在每个版本的两百例里都存在典型描述是“输入 N 个整数按从小到大排序”。老书的标准答案通常是这样int[] arr { 5, 3, 8, 1, 9, 2 }; for (int i 0; i arr.Length - 1; i) { for (int j 0; j arr.Length - 1 - i; j) { if (arr[j] arr[j 1]) { int temp arr[j]; arr[j] arr[j 1]; arr[j 1] temp; } } } foreach (int num in arr) { Console.Write(num ); }这段代码的逻辑本身没毛病两层循环外循环控制轮数内循环做相邻比较和交换。arr.Length - 1 - i是内循环边界因为每轮过后最大的数已经沉底无需再比较。真正的问题在于这个写法只能处理int[]一旦需要排序string[]或自定义对象数组就必须重写一份。我的改造建议是把它封装成泛型扩展方法顺便加上比较器参数适配现代代码风格public static class SortExtensions { public static void BubbleSortT(this T[] array, ComparisonT comparison) { if (array null) throw new ArgumentNullException(nameof(array)); if (comparison null) throw new ArgumentNullException(nameof(comparison)); for (int i 0; i array.Length - 1; i) { for (int j 0; j array.Length - 1 - i; j) { if (comparison(array[j], array[j 1]) 0) { (array[j], array[j 1]) (array[j 1], array[j]); } } } } }改造后调用方式变成了arr.BubbleSort((a, b) a.CompareTo(b))ComparisonT委托让排序规则变得完全可控。这里的元组交换语法(a, b) (b, a)是 C# 7.0 之后的特性老写法是临时变量接三步交换。两种都行但元组交换在代码审查时更易读。注意保留空参数校验书里的老代码不具备这种习惯但实际工程里这是基本素养。4.2 文件遍历题递归到迭代避开访问拒绝的坑文件操作题里有一道经典给定目录路径打印出下面所有子目录和文件名。老书里最常见的实现是递归调用逻辑干净但遇到无权限访问的子目录时整个程序直接崩溃。我当时刷到这道题时踩过一次报错是UnauthorizedAccessException当时一脸懵。我的方案是递归加异常捕获同时区分文件系统错误和业务错误using System; using System.IO; using System.Collections.Generic; public class DirectoryWalker { public static Liststring GetAllFiles(string root, string searchPattern *) { var result new Liststring(); WalkDirectory(new DirectoryInfo(root), result, searchPattern); return result; } private static void WalkDirectory(DirectoryInfo dir, Liststring results, string pattern) { FileInfo[] files; try { files dir.GetFiles(pattern); } catch (UnauthorizedAccessException) { Console.WriteLine($跳过无权限目录: {dir.FullName}); return; } catch (DirectoryNotFoundException) { Console.WriteLine($目录不存在或已被删除: {dir.FullName}); return; } foreach (var file in files) { results.Add(file.FullName); } DirectoryInfo[] subDirs; try { subDirs dir.GetDirectories(); } catch (UnauthorizedAccessException) { Console.WriteLine($跳过无权限子目录: {dir.FullName}); return; } foreach (var subDir in subDirs) { WalkDirectory(subDir, results, pattern); } } }GetFiles和GetDirectories分别放在独立的try-catch里这个细节很重要。因为一个目录可能文件可以读取但子目录没有访问权限单独捕获能保证文件列表仍然可用只是跳过无权限的子目录。searchPattern参数支持通配符比如*.txt或report?.doc用法上和其他 API 保持一致。这个例子跑出来的结果列表可以用于后续的批量改名、批量统计行数等操作落地价值远比单纯的打印要大。4.3 字符串频次统计从 ArrayList 到 Dictionary 的进化老书里统计词频的题当年用了很多ArrayList存键值对再手工比较代码冗长且容易出错。现代写法用DictionaryTKey, TValue一步到位不仅代码量少一个数量级性能也更好。using System; using System.Collections.Generic; using System.Linq; public static class TextStatistics { public static Dictionarychar, int CountCharacters(string input) { if (input null) throw new ArgumentNullException(nameof(input)); var counter new Dictionarychar, int(); foreach (char c in input) { if (char.IsWhiteSpace(c)) continue; if (counter.ContainsKey(c)) { counter[c]; } else { counter.Add(c, 1); } } return counter; } } // 使用示例 string text hello world hello csharp; var stats CountCharacters(text); foreach (var kvp in stats.OrderByDescending(p p.Value)) { Console.WriteLine($字符 {kvp.Key} 出现 {kvp.Value} 次); }这里的counter[c]依赖 Dictionary 索引器的特性键存在时返回当前值并支持赋值键不存在时直接索引会抛出异常所以必须先ContainsKey判断。我见过不少新手试图用counter[c]省掉判断结果运行时异常这就是对集合行为不熟的典型表现。char.IsWhiteSpace过滤掉空格、换行等空白字符让统计结果更聚焦实际内容。最后的OrderByDescending(p p.Value)来自 LINQ不改变原字典返回新的排序序列这在展示场景下非常实用。5. 刷两百例的常见翻车点与排查五个真实踩坑记录5.1 编译报错 CS0619现象老书里的Console.ReadLine()或某些System.Windows.Forms相关语句在新项目里编译时编译器提示“已过时”并报错。原因.NET 8 中部分 API 被标记为[Obsolete]编译器默认把过时警告提升为错误尤其是涉及安全或替代方案明确的 API。解决第一选择是查找替代 API比如WebClient换成HttpClient。第二选择是实在需要保留老语法时在文件顶部加#pragma warning disable CS0619只作用于当前文件。我建议优先做迁移pragma 是最后手段因为压制警告会让后续代码审查失去一个信号。5.2 控制台中文输出乱码现象Console.WriteLine(你好)输出变成浣犲ソ之类的乱码。原因.NET Core 进程默认输出编码是 UTF-8而旧版 Windows 控制台默认代码页可能是 GBK。两者不一致导致输出字节被错误解读。解决在入口最前面设置Console.OutputEncoding Encoding.UTF8;。如果你在 Windows Terminal 下运行这行就足够了如果仍跑在经典 cmd 里可以改成Console.OutputEncoding Encoding.GetEncoding(GB2312);但前提是先Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)。5.3 System.Drawing 绘图代码异常或界面空白现象书里用System.Drawing画的图形在 Windows 上还能显示在 Linux/macOS 上跑直接抛异常或者画出来是空的。原因System.Drawing.Common从 .NET 6 开始仅支持 Windows其他平台上报平台不支持异常。这和 GDI 的底层实现有关。解决如果只是练习绘图逻辑把目标运行时限制为 Windows在 csproj 里加RuntimeIdentifierwin-x64/RuntimeIdentifier。如果想跨平台换用图像处理库如 SkiaSharp但接口和思维模型完全不同。我的建议很简单跳过所有界面绘图题把时间留给算法和文件处理。5.4 File.ReadAllText 读老文本文件出现多余字符现象读取一个 GB2312 编码的 txt 文件中文正常但开头多了三个字符。原因这三个字符是 UTF-8 BOM 的字节序列被错误地按 GB2312 解码显示。文件实际是 UTF-8 带 BOM而你用File.ReadAllText默认编码去读时发生了什么取决于 .NET 版本和检测逻辑。解决统一指定编码读取不要依赖自动检测。先确认文件编码再决定参数File.ReadAllText(path, Encoding.GetEncoding(GB2312))。如果文件有 BOM.NET 的自动检测其实能正确处理乱码通常发生在无 BOM 的 UTF-8 文件被按其他编码读的情况。排查思路是先用十六进制查看器看文件头几个字节再决定编码参数。5.5 项目文件被自动通配符包含导致重复编译现象两百例代码文件全丢进项目目录后编译报大量“类型已存在”错误。原因SDK-style 项目默认启用EnableDefaultCompileItems会把项目目录下所有 .cs 文件自动加入编译。如果书自带示例代码和你的练习代码同名类就冲突了。解决在 csproj 里显式关闭默认编译项改为手工指定需要的文件。这样做的副作用是后续新增 .cs 文件都要手动编辑 csproj管理成本上升。另一种做法是保持默认但严格控制代码文件命名不重复。我个人习惯是保留默认把老书自带代码放legacy子目录并在 csproj 里排除该目录ItemGroup Compile Removelegacy/** / /ItemGroup这个配置写在Project节点内即可排除了整个legacy目录避免脏文件干扰主项目编译。6. 把两百例做成自己的工具箱三个实测有用的改造方向练习题和真实需求之间隔着一层翻译功夫。书里的例题是孤立的而现实需求总是组合型的。我在刷到三分之一时开始尝试改造把每个例题往“能复用的工具”方向拧。最成功的三个改造分别是批量文件改名器、日志文件统计器、通用排序扩展库。批量文件改名器脱胎于“遍历目录文件并打印”那道题。我加了一个规则参数比如把文件名里的[tmp]替换成日期或者统一给所有文件加前缀。核心逻辑仍然是遍历 字符串替换但包装成交互式命令行工具后在日常工作中处理照片归类、下载文件整理时非常顺手。日志统计器来自字符频次统计题我把输入从单个字符串换成日志文件统计每个错误等级出现的次数按频率排序输出。后来加了简单的过滤条件比如只看某段时间的日志几百行就搞定够用。通用排序扩展库就是前面 4.1 那段的泛型方法我收集了七八种排序算法的实现统一封装成扩展方法全部无依赖。虽然工程上很少手写排序但这段代码在面试讲解算法时很有说服力。做这些改造时有两点经验一是不要贪多一道题对应一个实际场景就够了为改造而改造会浪费时间二是一定要在自己真实遇到过的问题里选题材否则做完就没有维护的动力。我自己曾经犯过一个错把书里所有例题都改成现代语法后就觉得自己掌握了结果在项目里遇到老代码仍然一筹莫展。原因是改写的过程中我是在“翻译”不是在做“思考”。真正让我能力发生质变的转折点是放弃查看参考答案凭记忆重写关键逻辑写不出来再回去翻书。这个过程非常痛苦但每一道凭记忆写出来的题都成了真正属于自己的肌肉记忆。刷两百例的正确姿势不是“看完”而是“复写”。第一遍对着书敲代码理解逻辑第二遍合上书凭记忆写第三遍尝试改造。三遍下来一本老书的价值会被挖掘得透透的。环境问题、编码问题、API 过时问题这些都是技术债但解决它们本身也是重要的实战训练。希望帮到你。本文还有配套的精品资源点击获取