摘要： DeveloperExceptionPageMiddleware中间件利用呈现出来的错误页面实现抛出异常和当前请求的详细信息以辅助开发人员更好地进行纠错诊断工作，而ExceptionHandlerMiddleware中间件则是面向最终用户的，我们可以利用它来显示一个友好的定制化的错误页面。 阅读全文

摘要： 在《ASP.NET Core应用的错误处理[1]：三种呈现错误页面的方式》中，我们通过几个简单的实例演示了如何呈现一个错误页面，这些错误页面的呈现分别由三个对应的中间件来完成，接下来我们将对这三个中间件进行详细介绍。在开发环境呈现的异常页面是通过一个类型为DeveloperExceptionPageMiddleware中间件实现的 阅读全文

摘要： 由于ASP.NET Core应用是一个同时处理多个请求的服务器应用，所以在处理某个请求过程中抛出的异常并不会导致整个应用的终止。出于安全方面的考量，为了避免敏感信息的外泄，客户端在默认的情况下并不会得到详细的出错信息，这无疑会在开发环境下增加查错纠错的难度。对于生产环境来说，我们也希望最终用户能够根据具体的错误类型得到具有针对性并且友好的错误消息。ASP.NET Core提供了相应的中间件帮助我们将定制化的错误信息呈现出来，这些中间件都定义在“Microsoft.AspNetCore.Diagnostics”这个NuGet包中。 阅读全文

摘要： 当某个请求能够被成功路由的前提是它满足某个Route对象设置的路由规则，具体来说，当前请求的URL不仅需要满足路由模板体现的路径模式，请求还需要满足Route对象的所有约束。路由系统采用IRouteConstraint接口来表示路由约束，所以我们在接下来的内容中将路由约束统称为RouteConstraint。 在大部分情况下，约束都是针对路由模板中定义的某个路由参数，其目的在于验证URL携带的某部分的内容是否有效。不过也有一些约束与路由参数无关，这些约束规范往往是除URL之前的其他请求元素，比如前面提到的HttpMethodRouteConstraint检验的就是请求采用的方法。 阅读全文

摘要： 为这个星球上最强大的IDE，Visual Studio不仅仅提供了很多原生的特性，更重要的是它是一个可定制的IDE，比如自定义Project Template和Item Template就是一个非常有用的扩展点。这里我们主要关注Item Template，它时我们可以在“Add new Item”对话框中添加我们自定义的Item.我们之前自定义了一些Item Template，最近想在.NET Core项目中使用它们，但是失败了。今天为了这个折腾得够呛，不过好在最后还是解决了——虽然解决方案仅仅是添加一行代码 阅读全文

摘要： 然ASP.NET Core应用的路由是通过RouterMiddleware这个中间件来完成的，但是具体的路由解析功能都落在指定的Router对象上，不过我们依然有必要以代码实现的角度来介绍一下这个中间件。 阅读全文

摘要： 在《注册URL模式与HttpHandler的映射关系》演示的实例中，我们总是利用一个RouteBuilder对象来为RouterMiddleware中间件创建所需的Router对象，接下来我们就着重来介绍这个对象。RouteBuilder是我们对所有实现了IRouteBuilder接口的所有类型以及对应对象的统称。 阅读全文

摘要： ASP.NET Core应用中的路由机制实现在RouterMiddleware中间件中，它的目的在于通过路由解析为请求找到一个匹配的处理器，同时将请求携带的数据以路由参数的形式解析出来供后续请求处理流程使用。但是具体的路由解析功能其实并没有直接实现在RouterMiddleware中间件中，而是由一个Router对象来完成的。 阅读全文

摘要： ASP.NET Core的路由是通过一个类型为RouterMiddleware的中间件来实现的。如果我们将最终处理HTTP请求的组件称为HttpHandler，那么RouterMiddleware中间件的意义在于实现请求路径与对应HttpHandler之间的映射关系。对于传递给RouterMiddleware中间件的每一个请求，它会通过分析请求URL的模式并选择并提取对应的HttpHandler来处理该请求。除此之外，请求的URL还会携带相应参数，该中间件在进行路由解析过程中还会根据生成相应的路由参数提供给处理该请求的Handler。 阅读全文

摘要： DefaultFilesMiddleware中间件的目的在于将目标目录下的默认文件作为响应内容。我们知道，如果直接请求的就是这个默认文件，那么前面介绍的StaticFileMiddleware中间件会将这个文件响应给客户端。如果我们能够将针对目录的请求重定向到这个默认文件上，一切就迎刃而解了。实际上DefaultFilesMiddleware中间件的实现逻辑很简单，它采用URL重写的形式修改了当前请求的地址，即将针对目录的URL修改成针对默认文件的URL 阅读全文

摘要： 和StaticFileMiddleware中间件一样，DirectoryBrowserMiddleware中间本质上还是定义了一个请求地址与某个物理目录之间的映射关系，而目标目录体现为一个FileProvider对象。当这个中间件接收到匹配的请求后，会根据请求地址解析出对应目录的相对路径，并利用这个FileProvider获取目录的内容。目录的内容最终会以一个HTML文档的形式被定义，而此HTML最终会被这个中间件作为响应的内容，“目录浏览器”的实现原理就这么简单。 阅读全文

摘要： 我们通过《以Web的形式发布静态文件》和《条件请求与区间请求》中的实例演示，以及上面针对条件请求和区间请求的介绍，从提供的功能和特性的角度对这个名为StaticFileMiddleware的中间进行了全面的介绍，接下来我们将更近一步，将从实现原理的角度来进一步认识这个中间件。 阅读全文

摘要： 通过调用ApplicationBuilder的扩展方法UseStaticFiles注册的StaticFileMiddleware中间件帮助我们处理针对文件的请求。对于StaticFileMiddleware处理请求的逻辑，大部分读者都应该想得到：它根据请求的地址找到目标文件的路径，然后利用注册的ContentTypeProvider根据路径解析出与文件内容相匹配的媒体类型，默认情况下得到的媒体类型是根据目标文件的扩展名解析出来的。解析出来的媒体类型将作为响应报头Content-Type的值。StaticFileMiddleware中间件最终利用FileProvider读取文件的内容作为响应消息的主体。实际上，这个中间件在处理请求时比我们想象的要多得多，针对条件请求（Conditional Request）和区间请求（Range Request）的处理就没有在上面演示的实例中体现出来。 阅读全文

摘要： 虽然ASP.NET Core是一款“动态”的Web服务端框架，但是在很多情况下都需要处理针对静态文件的请求，最为常见的就是这对JavaScript脚本文件、CSS样式文件和图片文件的请求。针对不同格式的静态文件请求的处理，ASP.NET Core为我们提供了三个中间件，它们将是本章论述的重点。不过在针对对它们展开介绍之前，我们照理通过一些简单的实例来体验一下如何在一个ASP.NET Core应用中发布静态文件。 阅读全文

摘要： HostingEnvironment是承载应用当前执行环境的描述，它是对所有实现了IHostingEnvironment接口的所有类型以及对应对象的统称。HostingEnvironment类型是对IHostingEnvironment接口的默认实现。对于通过HostingEnvironment的四个属性（ApplicationName、EnvironmentName、WebRootPath和ContentRootPath） 承载的四个与执行环境相关的设置，在WebHostOptions对象上都具有对应的属性，后者是前者的数据来源。由于WebHostOptions对象是WebHostBuilder根据它采用的配置来创建的，所以这些设置最初来源于使用的配置。 阅读全文

摘要： 在《历数依赖注入的N种玩法》演示系统自动注册服务的实例中，我们会发现输出的列表包含两个特殊的服务，它们的对应的服务接口分别是IApplicationLifetime和IHostingEnvironment，我们将分别实现这两个接口的服务统称在ApplicationLifetime和HostingEnvironment。我们从其命名即可以看出ApplicationLifetime与应用的声明周期有关，而HostingEnvironment则用来表示当前的执行环境，本篇文章我们着重来了解ApplicationLifetime与整个AASP.NET Core应用的生命周期有何关系. 阅读全文

摘要： 日志记录不仅对于我们开发的应用，还是对于ASP.NET Core框架功能都是一项非常重要的功能特性。我们知道ASP.NET Core使用的是一个极具扩展性的日志系统，该系统由Logger、LoggerFactory和LoggerProvider这三个核心对象组成。我们可以通过简单的配置实现对LoggerFactory的定制，以及对LoggerProvider添加。 阅读全文

摘要： 在对ASP.NET Core管道中关于依赖注入的两个核心对象（ServiceCollection和ServiceProvider）有了足够的认识之后，我们将关注的目光转移到编程层面。在ASP.NET Core应用中基于依赖注入的编程主要涉及到两个方面，它们分别是将服务注册到ServiceCollection中，和采用注入的方式利用ServiceProvider提供我们所需的服务。 阅读全文

摘要： 我们一致在说 ASP.NET Core广泛地使用到了依赖注入，通过前面两个系列的介绍，相信读者朋友已经体会到了这一点。由于前面两章已经涵盖了依赖注入在管道构建过程中以及管道在处理请求过程的应用，但是内容相对分散和零碎，我们有必要针对这个主题作一个归纳性的介绍。采用依赖注入的服务均由某个ServiceProvider来提供，但是在ASP.NET Core管道涉及到两个不同的ServiceProvider，其中一个是在管道成功构建后创建并绑定到WebHost上的ServiceProvider，对应着WebHost的Services属性。另一个ServiceProvider则是在管道处理每个请求时即时创建的，它绑定当表示当前请求上下文上，对应着HttpContext的RequestServices属性，两个ServiceProvider之间存在着父子关系。 阅读全文

摘要： 注册的服务器和中间件共同构成了ASP.NET Core用于处理请求的管道， 这样一个管道是在我们启动作为应用宿主的WebHost时构建出来的。要深刻了解这个管道是如何被构建出来的，我们就必须对WebHost和它的创建者WebHostBuilder这个重要的对象具有深刻的理解。[ 阅读全文

摘要： 中间件的注册除了可以借助Startup对象（DelegateStartup或者ConventionBasedStartup）来完成之外，也可以利用另一个叫做StartupFilter的对象来实现。所谓的StartupFilter是对所有实现了IStartupFilter接口的类型及其对象的统称。 阅读全文

摘要： 跨程序集之间的类型转移帮助框架或者类库的提供者解决这样的难题：某个类型在框架1.0版本的时候定义在程序集A中，当升级到2.0的时候被转移到了程序集B中，使用旧版本的应用可以在不做任何修改的情况下直接对使用的升级后的框架程序集 阅读全文

摘要： 一个ASP.NET Core应用被启动之后就具有了针对请求的处理能力，而这个能力是由管道赋予的，所以应用的启动同时意味着管道的成功构建。由于管道是由注册的服务器和若干中间件构成的，所以应用启动过程中一个核心的工作就是完成中间节的注册。由于依赖注入在ASP.NET Core应用这得到非常广泛的应用，框架绝大部分的工作都会分配给我们预先注册的服务，所以服务注册也是启动WebHost过程的另一项核心工作。这两项在启动过程中必须完成的核心工作通过一个名为Startup的对象来承载。 阅读全文

摘要： 我们在《服务器在管道中的“龙头”地位》中对ASP.NET Core默认提供的具有跨平台能力的KestrelServer进行了介绍，为了让读者朋友们对管道中的服务器具有更加深刻的认识，接下来我们采用实例演示的形式创建一个自定义的服务器。这个自定义的服务器直接利用HttpListener来完成针对请求的监听、接收和响应，我们将其命名为HttpListenerServer。 阅读全文

摘要： ASP.NET Core管道由注册的服务器和一系列中间件构成。我们在上一篇中深入剖析了中间件，现在我们来了解一下服务器。服务器是ASP .NET Core管道的第一个节点，它负责完整请求的监听和接收，最终对请求的响应同样也由它完成。服务器是我们对所有实现了IServer接口的所有类型以及对应对象的统称。 阅读全文

摘要： ASP.NET Core管道虽然在结构组成上显得非常简单，但是在具体实现上却涉及到太多的对象，所以我们在 “通过重建Hosting系统理解HTTP请求在ASP.NET Core管道中的处理流程”（上篇、中篇、下篇） 中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在本系列 中，我们会还原构建模拟管道时可以舍弃和改写的部分，向读者朋友们呈现一个真是的HTTP请求处理管道。 ASP.NET Core 的请求处理管道由一个服务器与一组有序排列的中间件构成，前者仅仅完成请求监听、接收和响应这些与底层网络相关的工作，至于请求接收之后和响应之前的所有工作都交给中间件来完成。 阅读全文

摘要： 论是JavaScript还是C#程序，我们已经习惯了采用“链式调用”的方式进行编程，这样确实会使我们的程序变得很精练。采用这种链式调用方式的很多方式都是扩展方法。我们在定义这种扩展方法的时候，有一个地方值得我们注意。 阅读全文

摘要： ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道，我觉得可以分两个步骤来进行：首先，我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程；在对总体流程有了大致了解之后，我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造了一个“迷你版的管道”。 阅读全文

摘要： ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道，我觉得可以分两个步骤来进行：首先，我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程；在对总体流程有了大致了解之后，我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造了一个“迷你版的管道”。 阅读全文

摘要： ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道，我觉得可以分两个步骤来进行：首先，我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程；在对总体流程有了大致了解之后，我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造了一个“迷你版的管道”。 阅读全文

摘要： FileProvider构建了一个抽象文件系统，作为它的两个具体实现，PhysicalFileProvider和EmbeddedFileProvider则分别为我们构建了一个物理文件系统和程序集内嵌文件系统。总的来说，它们针对的都是“本地”文件，接下来我们通过自定义FileProvider构建一个“远程”文件系统，我们可以将它视为一个只读的“云盘”。由于文件系统的目录结构和文件内容都是通过HTTP请求的方式读取的，所以我们将这个自定义的FileProvider命名为HttpFileProvider。 阅读全文

摘要： 这是今天作项目支持的发现的一个关于WCF的问题，虽然最终我只是添加了一行代码就解决了这个问题，但是整个纠错过程是痛苦的，甚至最终发现这个问题都具有偶然性。具体来说，这是一个关于如何自动为服务接口（契约）的每个操作添加FaultContract与WCF服务元数据发布的问题。接下来通过一个简单的实例来说明这个因为少写了一行代码引发的血案。 阅读全文

摘要： ETW是Event Tracing for Windows的简称，它是Windows提供的原生的事件跟踪日志系统。由于采用内核（Kernel）层面的缓冲和日志记录机制，所以ETW提供了一种非常高效的事件跟踪日志解决方案。 阅读全文

摘要： 从微软推出第一个版本的.NET Framework的时候，就在“System.Diagnostics”命名空间中提供了Debug和Trace两个类帮助我们完成针对调试和跟踪信息的日志记录。在.NET Framework 2.0中，微软引入了TraceSource并对跟踪日志系统进行了优化，优化后的跟踪日志系统在.NET Core中又经过了相应的简化。.NET Core的日志模型借助TraceSourceLoggerProvider实现对TraceSource的整合，在正式介绍这个Logger之前，我们先来认识一下TraceSource跟踪日志系统中的三个核心对象 阅读全文

摘要： 面向Windows的编程人员应该不会对Event Log感到陌生，以至于很多人提到日志，首先想到的就是EventLog。EventLog不仅仅记录了Windows系统自身针对各种事件的日志，我们的应用也可以利用提供的API将日志消息写到EventLog中。与EventLog相关的API都定义在System.Diagnostics.EventLog这个类型中，我们不仅仅可以利用它读取、写入和删除日志，还可以使用它来创建和删除Event Source。.NET Core的日志模型利用EventLogLogger实现了与EventLog的集成，不过EventLogLogger使用的是一个抽象化的EventLog。 阅读全文

摘要： 定义在NuGet包“Microsoft.Extensions.Logging.Debug”中的DebugLogger会直接调用Debug的WriteLine方法来写入分发给它的日志消息。如果需要使用DebugLogger来写日志，我们需要将它的提供者DebugLoggerProvider注册到LoggerFactory上。由于定义在Debug类型中的所有方法都是针对Debug编译模式的，所以在只有针对Debug模式编译的应用中使用DebugLogger才有意义。这里将的“Debug编译模式”涉及到一个叫做“条件编译”的话题。 阅读全文

摘要： 对于一个控制台应用，比如采用控制台应用作为宿主的ASP.NET Core应用，我们可以将记录的日志直接输出到控制台上。针对控制台的Logger是一个类型为ConsoleLogger的对象，ConsoleLogger对应的LoggerProvider类型为ConsoleLoggerProvider，这两个类型都定义在 NuGet包“Microsoft.Extensions.Logging.Console”之中。 阅读全文

摘要： 配置的同步涉及到两个方面：第一，对原始的配置文件实施监控并在其发生变化之后从新加载配置；第二，配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。要了解配置同步机制的实现原理，先得从认识一个名为ConfigurationReloadToken的类型开始。 阅读全文

摘要： 记录各种级别的日志是所有应用不可或缺的功能。关于日志记录的实现，我们有太多第三方框架可供选择，比如Log4Net、NLog、Loggr和Serilog 等，当然我们还可以选择微软原生的诊断框架（相关API定义在命名空间“System.Diagnostics”中）实现对日志的记录。.NET Core提供了独立的日志模型使我们可以采用统一的API来完成针对日志记录的编程，我们同时也可以利用其扩展点对这个模型进行定制，比如可以将上述这些成熟的日志框架整合到我们的应用中。 阅读全文

摘要： 物理文件是我们最常用到的原始配置的载体，最佳的配置文件格式主要由三种，它们分别是JSON、XML和INI，对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。但是对于.NET Core的配置系统来说，我们习以为常的XML反倒不是理想的配置源，至少和JSON比较起来，它具有一个先天不足的劣势，那就是针对集合数据结构的支持不如人意。[ 阅读全文