《ASP.NET Core 6框架揭秘》勘误

P5第2段

原文：由于创建的是一个针对 ASP.NET Core 的可执行控制台应用，所以将 OutputType 和 TargetFramework 的属性分别设置为“Exe”和“net6.0”。
改为：由于创建的是一个针对 .NET 6的可执行控制台应用，所以将 OutputType 和 TargetFramework 的属性分别设置为“Exe”和“net6.0”。

P7第2段

原文：由于创建的是 ASP.NET Core 的应用程序，所以最终生成的程序集被保存在“\bin\Debug\net6.0\”目录下。
改为：由于创建的是 .NET 6的应用程序，所以最终生成的程序集被保存在“\bin\Debug\net6.0\”目录下。

P34第2段

原文：为了能够使 API，我们为 App2 添加“Dapr.AspNetCore”这个 NuGet 包的引用。将缓存相关的 3 个操作定义在 IResultCache 接口中。
改为：为了能够使 Dapr API，我们为 App2 添加“Dapr.AspNetCore”这个 NuGet 包的引用。将缓存相关的 3 个操作定义在 IResultCache 接口中。

P47第3段

原文：首先 ASP.NET Core MVC 框架在处理请求的过程中会根据路由解析生成参数，得到目标 Controller 的类型，然后自动创建对应的实例并指定对应的 Action 方法
改为：首先 ASP.NET Core MVC 框架在处理请求的过程中会根据路由解析生成参数，得到目标 Controller 的类型，然后自动创建对应的实例并执行对应的 Action 方法

P86第2段

原文：提示实现类型并非‘App.IFoobarbazqux’，因为它与其他‘App.IFoobourbazqwx’的注册服务不同
改为：提示实现类型并非‘App.IFoobarbazqux’，因为它与其他‘App.IFoobourbazqux’的注册服务不同

P87第1段

原文：Replace 方法会使用指定的 c 替换第一个具有相同服务类型的 ServiceDescriptor 对象，实际操作是先删除后添加。
改为：Replace 方法会使用指定的参数替换第一个具有相同服务类型的 ServiceDescriptor 对象，实际操作是先删除后添加。

P87第2段

原文：包含服务注册信息（TryAddEnumerable）的IServiceCollection 对象最终被用来构建作为依赖注入容器的IServiceProvider 对象。
改为：包含服务注册信息（ServiceDescriptor）的IServiceCollection 对象最终被用来构建作为依赖注入容器的IServiceProvider 对象。

P116第4段

原文：这两个特殊的FileProvider 类型都定义在“Microsoft.Extensions.FileProviders.Abstractions”这个NuGet 包中。
改为：这两个特殊的FileProvider 类型都分别定义在“Microsoft.Extensions.FileProviders.Abstractions”和“Microsoft.Extensions.FileProviders.Composite”NuGet 包中。

P121第4段

原文：PhysicalFileProvider 针对物理文件的变化监控是通过下面的PhysicalFilesWatcher 对象实现的，其Watch 方法内部会直接调用PhysicalFileProvider 的CreateFileChangeToken 方法，并返回 IChangeToken 对象。
改为：PhysicalFileProvider 针对物理文件的变化监控是通过下面的PhysicalFilesWatcher 对象实现的，其Watch 方法内部会直接调用PhysicalFilesWatcher 的CreateFileChangeToken 方法，并返回 IChangeToken 对象。

P143 第2段代码

原文:

public interface IConfigurationBuilder
{
    IEnumerable<IConfigurationSource> Sources { get; }
    Dictionary<string, object> Properties { get; }
    ...
}

改为：

public interface IConfigurationBuilder
{
    IList<IConfigurationSource> Sources { get; }
    IDictionary<string, object> Properties { get; }
    ...
}

P145最后1行

原文: 如果目标类型为Nullable<T>，则在原始值不是Null 或者空字符串的情况下会直接返回Null，否则会按照上面的规则将值转换成类型基础T。
改为：如果目标类型为Nullable<T>，则在原始值为Null 或者空字符串的情况下会直接返回Null，否则会按照上面的规则将值转换成类型基础T。

P175第2段代码

原文:

public bool TryGet(string key, out string value)
=> !string.IsNullOrEmpty(_config[key]);

改为：

public bool TryGet(string key, out string value)
{
    value = _config[key];
    !string.IsNullOrEmpty(_config[key]);
}

P189第3段

原文：当一个空的 Options 对象被实例化之后，OptionsFactory工厂会利用如下 ICongfigureOptions、ICongfigureOptions和 IPostConfigureOptions 这 3 接口表示的对象对它进行初始化。
改为：当一个空的 Options 对象被实例化之后，OptionsFactory工厂会利用如下 ICongfigureOptions、ICongfigureNamedOptions和 IPostConfigureOptions 这 3 接口表示的对象对它进行初始化。

P211第1段

原文：由于Debug 类型上的所有方法通过条件编译的形式被设置为仅针对Debug 模式有效，但是如果程序是在Debug 模式下进行编译的，就意味着针对WriteLine 方法的调用不会出现在编译生成的程序集中。
改为：由于Debug 类型上的所有方法通过条件编译的形式被设置为仅针对Debug 模式有效，但是如果程序是在非Debug 模式下进行编译的，就意味着针对WriteLine 方法的调用不会出现在编译生成的程序集中。

P218第2段

原文：在根据名称筛选出带订阅的目标 DiagnosticListener 对象之后，调用其 Subscribe 方法注册了一个 Observer>对象，并用它监听发出的日志事件。
改为：在根据名称筛选出待订阅的目标 DiagnosticListener 对象之后，调用其 Subscribe 方法注册了一个 Observer>对象，并用它监听发出的日志事件。

P220第2段

原文：当该方法被执行时，系统弹出“Chooser Just-In-Time Debugger”对话框，如图 7-8 所示。
改为：当该方法被执行时，系统弹出“Choose Just-In-Time Debugger”对话框，如图 7-8 所示。

P243第3段

原文：EventListener 对象只能接收预先想 EventSource 分发的日志事件的前提预先进行了订阅的事件。
改为：EventListener 对象能够接收 EventSource 分发日志事件的前提是预先进行了订阅的事件。

P290第3段

原文：如下面的代码片段所示，ActivitySource 类型提供了 Name（必须）和 Version（可选）两个属性。
改为：如下面的代码片段所示，ActivitySource 类型提供了 Name（必需）和 Version（可选）两个属性。

P292第1段

原文： ShouldListenTo 属性返回的Func<ActivitySource, bool>委托对象起到了过滤器的作用，当任意一个Activity 对象启动和终止时，它总是会将自身的ActivitySource 对象作为参数调用每个ActivityListener 的过滤器，只有
在返回True 的情况下，对应的过滤器才会被执行。
改为：ShouldListenTo 属性返回的Func<ActivitySource, bool>委托对象起到了过滤器的作用，当任意一个Activity 对象启动和终止时，它总是会将自身的ActivitySource 对象作为参数调用每个ActivityListener 的过滤器，只有
在返回True 的情况下，对应ActivityListener 的ActivityStarted/ActivityStopped委托才会被执行。

P315第1段

原文：如下面的代码片段所示， ConsdeLoggerProvider 类型上面标注了 ProviderAliasAttribute 特性并将别名设置为“Console”，
改为：如下面的代码片段所示， ConsoleLoggerProvider 类型上面标注了 ProviderAliasAttribute 特性并将别名设置为“Console”，

P319

原文

internal static ILoggingBuilder AddConsoleWithFormatter<TOptions>( this ILoggingBuilder builder, string name, Action<TOptions> configure) where TOptions: ConsoleFormatterOptions
{
    builder.AddFormatterWithName(name);
    builder.Services.Configure<TOptions>(builder.Services, configure);
    return builder;
}

改为

internal static ILoggingBuilder AddConsoleWithFormatter<TOptions>(this ILoggingBuilder builder, string name, Action<TOptions> configure) where TOptions: ConsoleFormatterOptions
{
    builder.AddFormatterWithName(name);
    builder.Services.Configure<TOptions>(configure);
    return builder;
}

P380第1段

原文：但 InstanceName 仅仅是逻辑上的名称，在数据库服务器上并不存在一个对应的数据实例。。
改为：但 InstanceName 仅仅是逻辑上的名称，在数据库服务器上并不存在一个对应的数据库实例。

P388第1段

原文：我们将这个唯一标识的名称设置为 HttpClient。
改为：我们将这个唯一标识称为HttpClient的名称。

P418第1段

原文：作为IDefaultHttpClientFactory 接口的默认实现，DefaultHttpClientFactory 最终完成了 HttpClient 对象的创建。
改为：作为IHttpClientFactory 接口的默认实现，DefaultHttpClientFactory 最终完成了 HttpClient 对象的创建。

P556第2段

原文：由于应用初始化过程中的很多操作都与当前的承载环境有关，所以承载环境必须在运行应用最初的环境就被确定下来，并在整个应用生命周期内都不能改变。如
改为：由于应用初始化过程中的很多操作都与当前的承载环境有关，所以承载环境必须在运行之初就被确定下来，并在整个应用生命周期内都不能改变。如

P558第1段

原文：如果利用 WebApplicationOptions 来对应用所在的承载环境进行设置，则上面演示的程序可以修改成如下形式。由于 WebApplicationOptions 并不包含 WebRootPath 对应的配置选项，如果程序运行后则会发现承载环境的这个属性为空。由
改为：如果利用 WebApplicationOptions 来对应用所在的承载环境进行设置，则上面演示的程序可以修改成如下形式。由于 WebApplicationOptions 并不包含 WebRootPath 对应的配置选项，如果程序运行后则会发现承载环境的这个属性为空。

P558第1段代码

原文：

var options = new WebApplicationOptions
{
 Args = args,
 ApplicationName = "MyApp",
 ContentRootPath = Path.Combine(Directory.GetCurrentDirectory(), "contents"),
 EnvironmentName = "staging"
};

改为：

var options = new WebApplicationOptions
{
 Args = args,
 ApplicationName = "MyApp",
 ContentRootPath = Path.Combine(Directory.GetCurrentDirectory(), "contents"),
 WebRootPath = Path.Combine(Directory.GetCurrentDirectory(), "contents","wwwroot"),
 EnvironmentName = "staging"
};

P582第3段

原文：表17-3 列举的众多特性接口在后续相关章节中都会涉及，目前我们只关心表示请求和响应的IHttpRequestFeatureIHttpResponseFeature 接口和IHttpResponseBodyFeature 接口。从下面的代码片段可以看出，这两个接口具有与抽象类HttpRequest 和HttpResponse 一致的定义。
改为：表17-3 列举的众多特性接口在后续相关章节中都会涉及，目前我们只关心表示请求和响应的IHttpRequestFeature接口、IHttpResponseFeature 接口和IHttpResponseBodyFeature 接口。从下面的代码片段可以看出，前两个接口具有与抽象类HttpRequest 和HttpResponse 一致的定义。

P619第1段

原文：Minimal API 只是在基于 IHost/IHostBuilder 的服务承载系统上进行了封装，它利用 WebApplication 和 WebApplicationBuilder 这两个类型提供了更加简洁的 Minimal API，同时提供了与现有 Minimal API 的兼容。
改为：Minimal API 只是在基于 IHost/IHostBuilder 的服务承载系统上进行了封装，它利用 WebApplication 和 WebApplicationBuilder 这两个类型提供了更加简洁的 API，同时提供了与现有 API 的兼容。

P622第3段

原文：WebApplicationBuitder 还定义了 Host 属性和 WebHost 属性，对应类型为 ConfigureHostBuilder 和 ConfigureWebHostBuilder，它们分别实现了 IHostBuilder 接口和 IWebHostBuilder 接口，其目的是复用 IHostBuilder 接口和 IWebHostBuilder 接口承载的 Minimal API（主要是扩展方法）。
改为：WebApplicationBuitder 还定义了 Host 属性和 WebHost 属性，对应类型为 ConfigureHostBuilder 和 ConfigureWebHostBuilder，它们分别实现了 IHostBuilder 接口和 IWebHostBuilder 接口，其目的是复用 IHostBuilder 接口和 IWebHostBuilder 接口承载的 API（主要是扩展方法）。

P675第2段

原文：在激活 ASP.NET Core 承载进程之前，ASP.NET Core Module 会选择一个可用的端口，该端口和当前应用的路径（该路径将作用 ASP.NET Core 应用的 PathBase）被写入环境变量，对应的环境变量名称分别为“ASPNETCORE_PORT”和“ASPNETCORE_APPL_PATH”。
改为：在激活 ASP.NET Core 承载进程之前，ASP.NET Core Module 会选择一个可用的端口，该端口和当前应用的路径（该路径将作为 ASP.NET Core 应用的 PathBase）被写入环境变量，对应的环境变量名称分别为“ASPNETCORE_PORT”和“ASPNETCORE_APPL_PATH”。

P697第2段

原文：但只有将另一个名为 ServeUnknownFileTypes 的属性设置为 True 表示支持位置文件类型，中间件才会采用这个默认设置的媒体类型。
改为：但只有将另一个名为 ServeUnknownFileTypes 的属性设置为 True 表示支持未知文件类型，中间件才会采用这个默认设置的媒体类型。

P699第3段

原文：为了使读者对 StaticFileMiddleware 中间件处理静态文件的请求有更加深刻的认识，下面采用相对简单的代码来重新定义这个中间件。这个模拟中间件具有与 StaticFileMiddleware 相同的功能，它能够将目标文件的内容采用正确的媒体类型响应给客户端，同时能够处理条件请求和区间请求。该中间件处理静态文件请求的整个处理流程大体上可以分为以下 3 个步骤。
改为：为了使读者对 StaticFileMiddleware 中间件处理静态文件的请求有更加深刻的认识，下面采用相对简单的代码来重新定义这个中间件。这个模拟中间件具有与 StaticFileMiddleware 相同的功能，它能够将目标文件的内容采用正确的媒体类型响应给客户端，同时能够处理条件请求和区间请求。StaticFileMiddleware 中间件处理静态文件请求的整个处理流程大体上可以分为以下 3 个步骤。

P715第2段

原文：一般来说，在利用某路由终节点与待路由的请求进行匹配时只需要考虑请求地址的路径部分，忽略主机（Host）名称和端口，但是一定要加上主机名称（含端口）的匹配策略。
改为：一般来说，在利用某路由终节点与待路由的请求进行匹配时只需要考虑请求地址的路径部分，忽略主机（Host）名称和端口，但是一定要加上主机名称（含端口）的匹配策略也是可以的。

P739第2段

原文：如下特性实现了上面几个接口，它们都被定义在“Microsoft.AspNetCore.Mvc”命名空间下，它们原本是为了 ASP.NET Core MVC 下的模型绑定服务的。值得一提的是， FromQueryAttribute 特性不被支持。
改为：如下特性实现了上面几个接口，它们都被定义在“Microsoft.AspNetCore.Mvc”命名空间下，它们原本是为了 ASP.NET Core MVC 下的模型绑定服务的。值得一提的是， FromQueryAttribute 特性不被支持。

P772第2段

原文：将DeveloperExceptionPageMiddleware 中间件注册到这两个路由分支上，采用的异常处理器都会将响应状态码设置为404。
改为：将ExceptionHandlerMiddleware中间件注册到这两个路由分支上，采用的异常处理器都会将响应状态码设置为404。

P804第1段

原文：程序运行之后，利用 Chrome 和 IE 访问请求注册的终节点，从图 23-1 可以看出，针对 Chrome 的两次请求的 Session ID 和会话状态值都是一致的，但是浏览器中显示的则不同。
改为：程序运行之后，利用 Chrome 和 IE 访问请求注册的终节点，从图 23-1 可以看出，针对 Chrome 的两次请求的 Session ID 和会话状态值都是一致的，但是IE浏览器中显示的则不同。

832第插图25-2

P839第1段

原文：RewriteMiddleware 中间件具有对应的 RewriteOptions 配置选项，重定向规则最终注册在 IList 对象的 Rules 属性中，具体的规则可以调用 Add 扩展方法添加到此列表中。
改为：RewriteMiddleware 中间件具有对应的 RewriteOptions 配置选项，重定向规则最终注册在 IList <IRule>对象的 Rules 属性中，具体的规则可以调用 Add 扩展方法添加到此列表中。

P884第2段

原文：这两个缺失的方法分别定义在如下 IAuthenticationHandler 的 IAuthenticationSignOutHandler 接口中。
改为：这两个缺失的方法分别定义在如下 IAuthenticationSignInHandler 和 IAuthenticationSignOutHandler 接口中。

P891第2段

原文：如下面的代码片段所示，IClaimsTransformation 接口提供的 TransformAsync 方法可以实现 ClaimsPrincipal 对象的转换或者加跟。
改为：如下面的代码片段所示，IClaimsTransformation 接口提供的 TransformAsync 方法可以实现 ClaimsPrincipal 对象的转换或者加工。

P895第1段

原文：当调用 AuthenticationBuilder 的 AuthenticationBuilder 注册认证方案时，需要同时指定认证处理器和对应配置选项的类型，该类型一般会派生如下 AuthenticationSchemeOptions 类型。
改为：当调用 AuthenticationBuilder 的 AddScheme方法注册认证方案时，需要同时指定认证处理器和对应配置选项的类型，该类型一般会派生如下 AuthenticationSchemeOptions 类型。

posted @ 2022-07-17 14:22 Artech 阅读(1889) 评论(25) 编辑收藏举报

刷新页面返回顶部