有一小段时间没有持续升级ABP框架了，最近就因应客户的需要，把ABP框架进行全面的更新，由于我们应用的ABP框架，基础部分还是会使用官方的内容，因此升级的时候需要把官方基础ABP的DLL进行全面的更新，以及对应的引用DLL也同步更新才行。不过在升级过程中还是很多奇奇怪怪的问题，本篇随笔针对出现的情况进行一系列的总结，以便后面有一个对照参考吧。
1、最新案例源码和NugGet程序包更新
ABP官方的基础模块更新速度还是很快的，一段时间过去，就跳过了几个版本号，我是在旧版本的基础上进行手动的NugGet更新，但是基于VS的Nugget总是更新卡顿，不知不觉就没有反应了，严重影响开发的效率。因此先从官方下载的Demo案例中把相关部分源码进行更新。
官方的案例源码下载地址是：https://aspnetboilerplate.com/Templates
1）最新案例源码结构和部分内容调整
我们从其中下载对应的源码，然后根据项目结构中的对应源码文件，使用Beyond Compare对比文件进行文件逐一对比，原则上除了个人扩展的部分，都以官方的源码做法为准即可。
目前ABP官方最新的DLL版本是5.3.0，可以下载的Demo版本是5.2.0，它们应该差别不大。下载下来的Aspnet-core部分的源码结构如下所示。
而我们的ABP框架是在这个基础上进行一定的结构优化，以更加方便快速的开发，以及结合代码生成工具进行快速的使用。
我们的VS项目结构 如下所示。
以上是VS里面解决方案的项目结构，我根据项目之间的关系，整理了一个架构的图形，如下所示。
上图中，其中橘红色部分就是我们为各个层添加的类或者接口，分层上的序号是我们需要逐步处理的内容。
应用服务层是整个ABP框架的灵魂所在，对内协同仓储对象实现数据的处理，对外配合Web.Core、Web.Host项目提供Web API的服务，而Web.Core、Web.Host项目几乎不需要进行修改，因此应用服务层就是一个非常关键的部分，需要考虑对用户登录的验证、接口权限的认证、以及对审计日志的记录处理，以及异常的跟踪和传递，基本上应用服务层就是一个大内总管的角色，重要性不言而喻。
回顾了解一下我们改造过的ABP开发框架的结构后，我们返回到版本升级的主体上来介绍。
目前我把VS的版本升级到最新，其.net framework支持4.8, 并单独安装了dotnetcore最新版本3.1，因此环境是最新的，而基础的ABP 5.3.0也是采用了.net core3.1。
对比源码，我们可以发现，Web.Host和Web.Core项目里面已经有所差异，IHostingEnvironment已经被抛弃使用，而采用dotnetcore最新对象IWebHostEnvironment来替代了。
替换最新源码为
因此Web.Host项目中的Module类也进行了调整。
相对应的Web.Core项目里面的Module也同时进行调整了。
2）NugGet程序包更新
Nugget程序包的更新，原则上可以选择单个项目进行更新，或者选择整个解决方案进行程序包的更新，前者可能相应速度快一些，后者由于解决方案项目数量问题，可能会较慢。
我早期的基础ABP版本是4.9，因此想一次性整个的解决方案的程序包进行更新，不过尝试多次，花了几个小时，都无法顺利进行项目的全部更新，于是单个项目进行更新，也非常慢。
于是也通过推荐采用Nugget最新地址进行更新，如下设置更新源。
在程序包源中添加：https://api.nuget.org/v3/index.json
响应速度相对快了一些，没有不经常的出问题了。
我们如果需要单独更新某个项目的程序包，那么需要选择项目，选择【管理Nugget程序包】进入界面更新即可。如下界面所示。
一般情况下，我们推荐对整个解决方案进行全面的程序包更新，如下选择解决方案，然后进入对应Nugget程序包管理界面更新即可。
这样的全部更新解决方案的程序包，如果能够顺利完成，那是皆大欢喜，不过可能会稍微慢一些。如果不行，只有逐个更新程序包了。
我之前选择这样的方式更新的时候，总是有一两个程序包更新出错，因此只有使用npm 控制台进行单独的升级了。
2、ABP框架基类封装接口命名调整
在更新ABP基础模块的时候，发现ABP的基础接口全部调整了命名，如原来的Get变为GetAsync，GetAll变为 GetAllAsync，Delete变为了DeleteAsync，Update变为了UpdateAsync，Create变为了CreateAsync。
也就是说，他们全部采用了异步名称的命名规则，在异步方法后面全部加上了Async作为标识。
我在之前模块介绍过ABP框架的基础接口。IAsyncCrudAppService定义了几个通用的创建、更新、删除、获取单个对象和获取所有对象列表的接口，接口定义如下所示。
namespace Abp.Application.Services
{
public interface IAsyncCrudAppService : IApplicationService, ITransientDependency
where TEntityDto : IEntityDto
where TUpdateInput : IEntityDto
where TGetInput : IEntityDto
where TDeleteInput : IEntityDto
{
Task Create(TCreateInput input);
Task Delete(TDeleteInput input);
Task Get(TGetInput input);
Task> GetAll(TGetAllInput input);
Task Update(TUpdateInput input);
}
}
现在这些接口全部调整如下所示了。
namespace Abp.Application.Services
{
public interface IAsyncCrudAppService : IApplicationService, ITransientDependency
where TEntityDto : IEntityDto
where TUpdateInput : IEntityDto
where TGetInput : IEntityDto
where TDeleteInput : IEntityDto
{
Task CreateAsync(TCreateInput input);
Task DeleteAsync(TDeleteInput input);
Task> GetAllAsync(TGetAllInput input);
Task GetAsync(TGetInput input);
Task UpdateAsync(TUpdateInput input);
}
}
那么这些我们都必须随着ABP框架的调整也同时进行接口和对应类实现的调整了。
例如对应的异步ApplicationService服务的基类封装，我们也需要调整对应的异步接口实现。
针对远程调用的ApiCaller接口和实现，我们也需要进行命名方面的统一调整，这样才能顺利进行异步接口的调用
我在之前随笔《ABP开发框架前后端开发系列---（10）Web API调用类的简化处理》有针对API调用层的简化处理做了说明，我们所有的API调用，基本都是通过统一的一个函数进行调用的。
统一调用处理的方法名称是DoActionAsync。
虽然由于前面介绍了应用服务层的接口很多接口增加了Async的后缀字符，但是客户端通过URL调用，这个Async是不需要的，也就是需要移除，我们之前组装的URL地址是根据函数名称，那么函数名称需要移除这个后缀的Async字样了。
这样系统就顺利跑起来了。服务端界面如下所示。
我们启动Winform客户端，界面如下所示。
登陆启动后主体界面如下所示