趁着武汉疫情，，在家研究本来2.2的框架升级到3.1的问题，在过程中遇到不少坑，好在放假有的是时间，一个一个解决，现做个简要记录，供大家参考。
保举当真看这篇文章

[https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.1&tabs=visual-studio](https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.1&tabs=visual-studio)

**此中，主要问题都是本来的包的版本依赖问题!花了很多时间去解决各个引用的包依赖的问题**

1.常见的其他网站都有提，好比：
移除包Microsoft.AspNetCore.App，已经不需要了

2.IHostingEnvironment酿成了IWebHostEnvironment

3. 在Microsoft.AspNetCore.Http.HttpRequest.EnableRewind()这个要领，升级为Request.EnableBuffering ()

4.如果呈现：
System.TypeLoadException:“Could not load type ‘Microsoft.AspNetCore.Mvc.MvcJsonOptions‘ from assembly ‘Microsoft.AspNetCore.Mvc.Formatters.Json, Version=3.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60‘.”
最后升级swagger版本g到最新的5.0得到解决，但是升级swagger,又发明：
IDocumentFilter 变动了接口，
定名空间也改削了：升级为using Microsoft.OpenApi.Models;
将tag=>OpenApiTag
本来的接口要领改削为：
public void Apply(OpenApiDocument swaggerDoc, DocumentFilterContext context)

swagger示例：

```
services.AddSwaggerGen(options =>
{
options.SwaggerDoc("v1", new OpenApiInfo
{
Title = "API接口文档",
Version = "v1",
Description = "API v1",
Contact = new OpenApiContact { Name = "wadereye", Email = "wader129-qq.com" }
});
options.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
{
Description = "......",
Name = "Authorization",
//这两个参数均有改削
In = ParameterLocation.Header,
Type = SecuritySchemeType.ApiKey
});

options.AddSecurityRequirement(new OpenApiSecurityRequirement {
{
new OpenApiSecurityScheme
{
Reference = new OpenApiReference
{
Type = ReferenceType.SecurityScheme,
Id = "Bearer"
}
},
new string[] { }
}
});

...
});
```

5.如果呈现：

System.MissingMethodException:“Method not found: ‘Autofac.Builder.DeferredCallback Autofac.ContainerBuilder.RegisterCallback(System.Action`1<Autofac.Core.IComponentRegistry>)‘.”

是autofac的版本问题，autofac我一开始更新到5.0,处处报错，后来检察5.0的文档，发明更新较多，于是又将相关的autofac 5.0包降到最新的4.9.4，很多问题得以解决。

6.如果你以前用过context.Resource as AuthorizationFilterContext这样的，在asp.net core 3.0已经不撑持了。这个坑了我半天才找到解决方案。
在issue里找到这篇文章：
[https://github.com/aspnet/AspNetCore.Docs/issues/12564](https://github.com/aspnet/AspNetCore.Docs/issues/12564)

才发明其实在官方2.2升3.1的文章有介绍，只是一开始没看，原文这样介绍的：
#### Custom authorization handlers[](https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.1&tabs=visual-studio#custom-authorization-handlers)

If the app uses custom [authorization handlers](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-3.1#authorization-handlers), endpoint routing passes a different resource type to handlers than MVC. Handlers that expect the authorization handler context resource to be of type [AuthorizationFilterContext](https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.filters.authorizationfiltercontext) (the resource type [provided by MVC filters](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-3.1#accessing-mvc-request-context-in-handlers)) will need to be updated to handle resources of type [RouteEndpoint](https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.routing.routeendpoint) (the resource type given to authorization handlers by endpoint routing).

MVC still uses `AuthorizationFilterContext` resources, so if the app uses MVC authorization filters along with endpoint routing authorization, it may be necessary to handle both types of resources.

google翻译如下：
自界说授权措置惩罚惩罚措施 如果应用使用自界说授权措置惩罚惩罚措施，则端点路由会将与MVC差此外资源类型通报给措置惩罚惩罚措施。期望授权措置惩罚惩罚措施上下文资源的类型为AuthorizationFilterContext（由MVC过滤器供给的资源类型）的措置惩罚惩罚措施将需要更新，以措置惩罚惩罚RouteEndpoint类型的资源（端点路由供给给授权措置惩罚惩罚措施的资源类型）。
MVC仍使用AuthorizationFilterContext资源，因此，如果应用措施使用MVC授权过滤器以及端点路由授权，则可能有须要措置惩罚惩罚两种类型的资源。

所以获取的方法变了，很多需要通过endpoint的方法去获取。

具体的可以通过这篇文章来了解详细：