搞企业信息化这些年我手里过的ERP源码起码有七八套但要说最适合拿来练手和做二次开发的还是那两套C#写的一套是.NET Framework时代的WebForms单体架构轻、直白、改起来特别痛快另一套是.NET Core时代的前后端分离架构模块划分清晰、接口规范适合团队协作。这篇文章就把这两套C# ERP源码从解压、环境配置、跑起来到真正动手改业务流程、加模块、调报表的完整路径捋一遍中间踩过的坑和排查手段也一并交代清楚。不夸张地说照着走一遍大多数中等难度的二次开发需求你都能接得住。1. 两套ERP源码的定位差异为什么同时折腾两套1.1 第一套经典WebForms单体ERP先说我最早接触的那套。它是典型的WebForms架构整个系统就是一个大工程界面、业务逻辑、数据访问三层混在一个站点里。好处是门低Visual Studio里F5一按就能跑页面直接拖控件绑定数据一个做传统桌面开发转过来的同事一个下午就能上手改页面。这套的源码结构非常有年代感App_Code下面堆着一堆公共类页面后置代码里夹杂着SQL拼接存储过程占了业务逻辑的大头。它的数据层高度依赖存储过程很多业务改动其实不用碰C#代码直接在SQL Server里改存储过程就行这也是很多老企业愿意继续用它做底子的原因。当然它的问题也很明显没有接口层后续想接小程序、App全靠另起炉灶页面状态管理依赖ViewState一不注意就出现回传数据丢失并发能力一般适合几百人规模的公司内部使用。如果读者接手的是老项目维护和老流程改造这套架构几乎是必须面对的现实。1.2 第二套Core版模块化ERP第二套是后出现的基于.NET Core 3.1/6.0重构的一套模块化平台WebAPI 前端框架分离前后端通过JSON交互。源码按模块分包基础数据、采购、销售、库存、财务、报表每个模块独立成项目引用关系一眼能看清。这套明显是为二次开发设计的。它提供了统一的权限中间件每个接口打上权限特性标签就能控制访问菜单和按钮的配置存在数据库里前端根据权限动态渲染。相比老架构它把加一个页面这件事变成了写接口写页面配菜单三个标准化动作团队协作时互相不打架。它的门槛略高一些至少要懂RESTful接口的基本约定、依赖注入的用法、还有前端框架的组件化思维。但只要跨过这个坎后面加模块、接对接、二次开发的体验比老架构好不止一个量级。1.3 我的选型判断我为什么强调两套都值得折腾因为现实项目里两类源码都在跑。很多公司的主力系统还是十年前那套WebForms业务跑得好好的但老板今天要手机审批、明天要电商对接逼着你做接口改造而新启动的项目选型基本都会落到Core版这类现代化架构。两套都摸过才有能力跟客户说我能帮你把老系统盘活也能给你搭一套能长期演化的新系统。选型时我的建议很简单如果现状是维护多、需求急、还没有专职前端那老架构快速出活反而是优势如果有团队分工、系统要长期迭代、后续还有对接需求Core版是更稳的底子。不要盲目追新也不要因为老就急着推翻。2. 环境配置全记录让两套源码在本机跑起来2.1 数据库准备脚本执行与数据初始化两套源码都依赖SQL Server我先说通用的那套流程。源码包里一般附带database文件夹里面有完整建库脚本和初始化数据脚本。我第一次折腾的时候犯过一个低级错误直接在SSMS里把整本脚本一次性执行报了上百个错误后来才发现脚本有严格的执行顺序——先建库再建表再插基础数据最后跑存储过程。正确的做法是分三步走第一步新建一个数据库名字跟源码里的连接字符串对齐第二步按脚本文件名的数字前缀顺序逐个执行每跑完一个看消息窗口有没有报错第三步用源码自带的示例数据脚本导入基础数据这样登录进去就有测试账号和演示数据可用。登录账号那边也踩过坑。两套源码默认都用SQL Server身份验证连接本机安装时如果只开了Windows身份验证就会一直提示用户登录失败。需要在SSMS里把服务器属性改为SQL Server和Windows身份验证模式然后执行一行命令给sa账号设置密码并启用ALTER LOGIN sa WITH PASSWORD 你的强密码; ALTER LOGIN sa ENABLE;注意这只是本机开发的做法涉及真实环境密码策略和账号权限要按企业规范来不能直接套用sa。2.2 连接字符串与IIS部署细节老那套WebForms版的连接字符串在web.config里是一个典型的ADO.NET连接串。本机默认实例可以这么写connectionStrings add nameERPConnection connectionStringserver.;databaseYourDB;uidsa;pwd你的密码;MultipleActiveResultSetstrue / /connectionStrings这里有个容易被忽略的点serverlocalhost和server.在某些环境表现不一样。如果机器上有多个SQL Server实例必须写成server机器名\实例名这种格式否则会连到默认实例去然后报找不到数据库。IIS部署老版本时最容易翻车的是应用程序池配置。右键站点所在应用程序池把.NET CLR版本改成v4.0托管管道模式建议先试集成模式如果页面出现请求在此配置中不受支持之类的错误再切到经典模式试。还有一点64位系统上如果引用了32位的第三方组件记得在应用程序池高级设置里启用32位应用程序。Core版那边配置简单很多数据库连接串放在appsettings.json里。首次跑起来之前记得先确认目标框架版本用命令行看下本机装的SDK是否匹配dotnet --list-sdks dotnet --list-runtimes版本不匹配会直接提示要使用指定的SDK生成项目这时候去官网装对应版本就行装多个版本也不冲突。2.3 版本兼容性与本地运行环境清单两套源码跑起来需要的环境其实不多但版本敏感。老那套要求Visual Studio里装上.NET Framework 4.x开发包WebForms项目在VS里不需要额外组件直接打开sln就能编译Core版要求装了对应版本的.NET SDK如果项目是6.0就至少得6.0以上的SDK。前端部分第二套源码如果在Visual Studio里启动WebAPI和后端页面可以一起跑如果前端是独立工程需要先启后端服务再单独启前端开发服务器浏览器访问前端地址。头一次跑的时候我老是搞混后端端口和前端端口后来就固定下来后端一律跑在5000段端口前端是3000段。部署上给两张速查表方便保存项目老WebForms版Core版运行时.NET Framework 4.x.NET Core / .NET 6数据库SQL Server 2008R2及以上SQL Server 2012及以上部署方式IIS站点IIS/Apache或Windows服务自宿主连接串位置web.configappsettings.json配置修改后回收应用程序池重启服务或热重载提示本机调试时数据库版本和源码要求版本不要差太多。尤其是老的存储过程写法在SQL Server 2019以上某些旧语法会触发兼容性问题真遇到就把数据库兼容级别调低执行ALTER DATABASE YourDB SET COMPATIBILITY_LEVEL 110能省很多事。3. 二次开发实操改权限、调报表、加模块3.1 登录认证与权限改造两套源码的权限模型思路其实一脉相承用户表、角色表、菜单表、角色菜单关联表。老版还多一张按钮权限表控制每个角色在某个页面上能看到哪些操作按钮。我接到的第一个改权限需求是只让仓库主管看到审核按钮。在WebForms版本里这个逻辑写在页面加载事件里判断当前用户角色再设置按钮的Visible属性。找到那段代码之后改动其实就两行if (!IsInRole(WarehouseManager)) { btnApprove.Visible false; }但这种写法的隐患也要说清楚前端隐藏按钮只是友好提示真正安全的做法是后端接口再校验一次权限。老架构里很多人忽略这个结果用户猜一下URL就能直接调后台功能。做权限改造时前后端双重校验才是标准的。Core版这块就正规很多。它有一个权限中间件检查每个请求上的JWT令牌里携带的用户角色和接口特性标签是否匹配。新增一个权限点只要在控制器方法上加上对应的特性标记[Permission(Stock:Approve)] public IActionResult Approve(long id) { // 审批逻辑 }然后在前端菜单配置里勾选对应权限码就行不用再碰页面逻辑。3.2 报表自定义两套架构各走各路报表这块是我花时间最多的地方。老版用的是水晶报表Crystal Reports它有一个绕不开的坑服务端必须安装和开发环境完全对应的运行时版本否则报数据库登录失败或者缓冲区长度之类的诡异错误。而且水晶报表的报表文件.rpt是二进制格式想调整字段位置必须安装设计器不能在浏览器端动态改。我的经验是老系统里报表需求频繁的不用强磕水晶报表。可以把报表改造成查询出数据后用GridView直接呈现导出Excel这样既绕开组件依赖用户导出数据自己整理也方便。导出Excel的代码不复杂找一个开源组件把DataTable转成二维数组生成文件即可实测下来稳定。Core版那套没有用重型报表组件采用后端查询接口前端渲染表格导出的方案。导出走的是服务端生成文件前端触发下载。这思路对中小企业足够开发速度快、样式可控后续要换成专业报表服务也保留接口原样。3.3 完整走一遍新增一个客户回访管理模块这是我觉得最有参考价值的部分用两套架构分别实现同一个简单模块能直观看出差异。业务需求很简单销售每天记录客户回访列表能按客户和时间筛选能新增、编辑、删除回访记录。范围限定在一个角色。老WebForms版本的做法是四步建表、写存储过程、拖页面、挂菜单。建表不用多说存储过程写一个分页查询和一个新增/更新过程的合并页面用GridView列表FormView表单处理编辑最后在菜单表里插一条记录权限关联表里把新菜单挂到销售角色上。整个过程大概半天快的原因在于这套架构没有中间层页面直接调存储过程。Core版是另一种节奏。建表之后要写实体类、写DTO、写仓储接口、写控制器、写前端页面每个环节之间还要约定字段命名规范。好处是职责清楚坏处是初次写会觉得琐碎。走通一个模块之后后面所有模块都能复制这个模板速度会迅速提上来。这里给一个通用模板新增模块之前先搞清楚源码里有没有现成的单表CRUD示例模块比如部门管理、客户管理直接把它整目录复制一份然后全局替换表名和页面名可以少写大量重复代码。框架类项目基本都是这么干的翻一下源码比从零开始省一半时间。4. 常见问题与排查技巧实录4.1 报错速查表我遇到过的典型问题我把两个环境里反复出现的报错整理成了一张速查表排查时直接对着找思路现象可能原因处理建议登录提示用户登录失败数据库账号未启用或密码错误按上文SQL语句启用sa账号确认连接串密码页面提示未能加载文件或程序集引用的DLL版本不符或未复制检查bin目录删除后重新生成确认目标平台站点打开HTTP 500.19IIS配置权限或缺少功能组件安装IIS相关功能给站点目录添加用户读取权限请求被CORS策略阻止Core版前端跨域调用后端在Program.cs里配置CORS服务并添加前端地址白名单API返回404但路由看起来没错控制器特性路由与请求地址不匹配打开Swagger接口文档按文档地址逐个核对老版点击按钮后刷新丢失数据ViewState过大或控件ID冲突检查页面ViewState开关把不必要的大对象排除在状态保存外速查表只是定位方向真正的排查要靠日志。老版可以在Global.asax的Application_Error事件里记录异常详情Core版更简单打开控制台输出启动信息配合编程工具的服务端跟踪报错位置基本一目了然。4.2 几个保命的调试技巧第一个技巧是别急着改代码。遇到报错先把完整堆栈信息复制出来看内层异常而不是最外层提示。我见过太多人卡在未将对象引用设置到对象的实例这种最常见错误上其实内层已经写了具体是哪个表没查到数据往下翻一层就有答案。第二个技巧是善用数据库端排查。二次开发里很多问题不在C#代码而在SQL。老版跑完后在SQL Server事件探查器里能看到实际执行的语句参数值和耗时都看得清清楚楚Core版比较方便直接在上面的日志记录里开启EF Core的SQL日志开关会输出所有执行语句方便核对分页、排序、参数化是否正确。第三个技巧是版本管理。两套源码在做二次开发之前先提交一次干净的初始版本到代码托管平台之后每改一个功能提交一次。没有版本管理做二次开发就是裸奔改坏了想回退都无从下手。这个小动作在我实际项目里救了我无数次。4.3 孤立账号与数据库迁移的坑还有一个高频场景是把客户现场的数据库拷到本地调试。用备份文件还原后登录经常报无法打开用户默认数据库这是因为数据库里的登录账号和本机SQL Server的账号对应关系丢失了。老版本的修复办法是执行系统存储过程重新映射USE YourDB; EXEC sp_change_users_login Auto_Fix, erp_user;新版本语法换成了ALTER USERUSE YourDB; ALTER USER erp_user WITH LOGIN erp_user;这个坑不要等到现场才想起本地演练环境提前跑一遍迁移流程能省掉很多尴尬。5. 我个人实操中的几点体会文章写到最后分享几个从实际操作里攒出来的经验。第一不管哪套源码读代码顺序永远是先看数据库脚本、再看公共类、最后看页面。很多业务规则其实沉淀在存储过程和公共方法里跳过数据层直接看页面会一头雾水。我看老那套WebForms源码时花了两天时间把它的存储过程清单挨个过了一遍后面所有页面改动都顺畅多了。第二二次开发最忌讳拿到源码就加功能。需求到手之后先在源码里找到最接近的现有模块研究它是怎么组织的再说改动方案。很多时候你会发现所谓的新需求只是老功能的参数变化稍微配置一下就好完全不用动代码。第三两套源码各有适合的场景。自己学习练手我建议先攻老版因为它把ERP最基本的业务模型摊开给你看表结构、单据流、库存逻辑一目了然等理解了业务本质再转到Core版学习工程化、接口化、团队协作的做法。两套啃下来你会形成业务理解 技术实现两条腿走路的能力这是做企业应用开发最值钱的底子。