C# 与 .NET 开发
改变 .NET 应用，同时保留它承载的业务规则。
成熟的 C# 应用往往比文档更了解业务。我们先追踪变更依赖的行为，再实现约定的功能、集成或运行时升级，并建立验证方式，确认哪些原有行为必须保留。
直接回答
Wavect 在明确兼容性与验收范围的前提下，处理 C#/.NET 应用、API 和配套服务。承诺迁移或替换之前，先评估现有运行时、操作系统与依赖约束。
适用情况
- 需要扩展现有 C# 应用或 API 的团队
- 需要受控依赖升级或运行时升级的企业
其他服务可能更合适
- 假定任何 Windows 应用都能自动转换为跨平台产品
- 尚需恢复访问权限和明确责任的供应商交接
先明确要修改哪一类 .NET 应用
我们记录运行时、项目类型、NuGet 依赖、数据库提供程序和部署环境。ASP.NET API、后台工作进程与 Windows 桌面应用有不同约束。初步评估会指出未经验证的假设，以及值得优先测试的业务路径。如果代码库权限、凭据或责任仍不清楚，应先从软件接管开始。
沿着业务操作检查每条边界
新增端点或页面可能影响授权、持久化和后续任务。我们追踪这些责任，让业务规则可以测试，并在影响正确性的地方检查资源生命周期和异步调用。数据访问还需要考虑事务边界、并发修改冲突，以及现有记录的兼容性。外部副作用需要自己的重试和核对规则；数据库事务不会自动控制另一个服务。
运行时升级首先是兼容性决定
我们对比当前项目与拟采用的运行时，检查使用中的包、API 和平台假设。.NET Framework 与现代 .NET 不能视为同一个名称，依赖 Windows 的行为也需要明确评估。Microsoft 移植概览是这项评估的参考。更广泛的替换策略仍属于遗留系统现代化；把工作负载迁往另一环境则属于云迁移。
审批流程更新后，待处理申请仍然有效
示例验收场景：一个 C# 服务增加第二级审批，但系统中仍有旧流程下的待处理申请。测试覆盖新旧记录、授权角色，以及两个用户同时作出冲突决定的情况。发布演练包括一次失败的部署，以及事先约定的数据恢复流程。仅仅编译成功并不构成验收。这里描述的是可能采用的验证方案，不是已发布的客户成果。
把变更与运行假设一起交付
您会获得源代码修改、回归检查、依赖决策，以及说明剩余平台限制的发布记录。我们记录数据库变更如何影响应用回滚，不假定所有迁移都能逆转。请准备可工作的构建环境、代表性测试数据，以及能确认业务规则的负责人。后续持续维护可以通过软件维护另行约定。
开始前的常见问题
我们会先评估框架、库和运行环境，再约定范围。有时可以先完成有价值的改进，而不必立刻把整个应用迁到另一种运行时。
只有在明确约定并验证这个目标时才可以这样判断。Windows 专用 API、桌面框架和依赖仍可能限制应用，即使部分代码已经使用现代 .NET。
只有在证据支持、且范围明确包含时才会这样做。我们先检查现有查询、事务行为和数据兼容性，不把更换工具本身作为目标。
工程工作可以在交接之后进行，也可以配合交接。但访问恢复、合同和服务连续性属于软件接管范围，这些责任会单独明确。