Anduin Xue
Anduin Xue

Anduin's Tech Blog

C#

11
DEC

Consolidate all Entity-Framework database migrations to one migration

这篇文章探讨了如何在Entity Framework Core中通过合并数据库迁移以解决迁移文件过多导致的性能问题。当代码重构或迁移文件积累影响编辑器响应时开发者可能需要重置迁移历史但直接删除代码文件会导致数据库更新失败。文章提出了一种在保留数据前提下将所有迁移合并为单个"Init"迁移的策略包括删除迁移文件清空迁移历史表生成新迁移并临时注释迁移方法通过数据库更新记录虚拟历史再恢复代码逻辑的完整流程。该方案特别强调了多环境部署场景下需要逐个数据库重复操作的注意事项同时提醒开发者在操作前必须进行数据备份。通过这种"历史重写"的方式开发者可以将复杂的迁移历史简化为单一入口但这种方法也带来了数据一致性风险和部署流程复杂度的权衡。当面对微服务架构中的多数据库场景时如何在保持迁移灵活性与维护成本之间取得平衡这个问题值得每个使用EF Core的开发者深入思考。--Qwen3

ASP.NET Core C# .NET Core Entity Framework SQL Server EF Core
10
DEC

Upgrade existing class library to .NET Core 3.0

在.NET Core 3.0升级过程中如何避免框架引用冲突与语言特性陷阱？当传统类库迁移到新版本时TargetFramework设置可能引发NETSDK1080警告揭示了框架依赖管理的深层逻辑——Web项目必须使用Microsoft.NET.Sdk.Web SDK自动继承共享框架而Razor库需显式声明FrameworkReference并启用AddRazorSupportForMvc属性非Web项目则需谨慎评估是否需要引入ASP.NET Core框架。这种差异化的处理方式背后暗含着.NET生态对模块化设计的哲学思考：框架依赖究竟应该隐式继承还是显式声明？当C# 8.0新特性在旧版语言版本下报错CS8107时LangVersion配置的必要性提醒我们技术升级不仅是功能迭代更是开发规范的重构。这些看似零散的技术细节实则构成了现代.NET开发的核心认知框架：如何在SDK魔版化与手动配置之间找到平衡点？当框架引用与语言特性产生耦合时开发者应该如何构建可维护的依赖关系图谱？升级过程中的每个警告代码都像是技术债务的预警信号引导我们重新审视代码架构的深层设计逻辑。--Qwen3

C# class library .NET Core .NET Core 3.0 PackageReference FrameworkReference