摘要： 较之传统通过App.config和Web.config这两个XML文件承载的配置系统，.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源，如果采用物理文件作为配置源，我们可以选择不同的格式(比如XML、JSON和INI等) 。如果这些默认支持的配置源形式还不能满足你的需求，我们还可以通过注册自定义ConfigurationSource的方式将其他形式数据作为我们的配置来源。 阅读全文

摘要： 一个物理文件可以直接作为资源内嵌到编译生成的程序集中。借助于EmbeddedFileProvider，我们可以统一的编程方式来读取内嵌于某个程序集中的资源文件 阅读全文

摘要： ASP.NET Core应用中使用得最多的还是具体的物理文件，比如配置文件、View文件以及网页上的静态文件，物理文件系统的抽象通过PhysicalFileProvider这个FileProvider来实现，该类型定义在NuGet包“Microsoft.Extensions.FileProviders.Physical”中。我们知道System.IO命名空间下定义了一整套针操作物理目录和文件的API，实际上PhysicalFileProvider最终也是通过调用这些API来完成相关的IO操作的。[ 阅读全文

摘要： 在《读取并监控文件的变化》中，我们通过三个简单的实例演示从编程的角度对文件系统做了初步的体验，接下来我们继续从设计的角度来继续认识它。这个抽象的文件系统以目录的形式来组织文件，我们可以利用它读取某个文件的内容，还可以对目标文件试试监控并捕捉它的变化。这些基本的功能均由相应的FileProvider来提供，从某种意义上讲FileProvider代表了整个文件系统。 阅读全文

摘要： ASP.NET Core 具有很多针对文件读取的应用。比如我们倾向于采用JSON文件来定义配置，所以应用就会涉及针对配置文件读取。如果用户发送一个针对物理文件的HTTP请求，应用会根据指定的路径读取目标文件的内容并对请求予以响应。在一个ASP.NET Core MVC应用中，针对View的动态编译会涉及到根据预定义的路径映射关系来读取目标View。这些不同应用场景都会出现一个FileProvider对象的身影，以此对象为核心的文件系统提供了统一的API来读取文件的内容并监控内容的改变。 阅读全文

摘要： 旨在生成Options对象的配置绑定实现在IConfiguration接口的扩展方法Bind上。配置绑定的目标类型可以是一个简单的基元类型，也可以是一个自定义数据类型，还可以是一个数组、集合或者字典类型。通过前面的介绍我们知道ConfigurationProvider将原始的配置数据读取出来后会将其转成Key和Value均为字符串的数据字典，那么针对这些完全不同的目标类型，原始的配置数据如何通过数据字典的形式来体现呢？ 阅读全文

摘要： 置的原子结构就是单纯的键值对，并且键和值都是字符串，但是在真正的项目开发中我们一般不会单纯地以键值对的形式来使用配置。值得推荐的做法就是将相关的配置定义成一个Options类型，并采用与类型定义想匹配的结构来定义原始的配置，这样就能利用它们之间的映射关系将读取的配置数据绑定为Options对象，我们将这种编程模式称为“Options模式”。 阅读全文

摘要： 在《.NET Core采用的全新配置系统[1]: 读取配置数据》中，我们通过实例的方式演示了几种典型的配置读取方式，其主要目的在于使读者朋友们从编程的角度对.NET Core的这个全新的配置系统具有一个大体上的认识，接下来我们从设计的维度来重写认识它。通过上面演示的实例我们知道，配置的编程模型涉及到三个核心对象，它们分别是Configuration、ConfigurationSource和ConfigurationBuilder。如果从设计层面来审视这个配置系统，还缺少另一个名为ConfigurationProvider的核心对象，总得来说，.NET Core的这个配置模型由这四个核心对象组成。 阅读全文

摘要： 提到“配置”二字，我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影，那就是我们再熟悉不过的app.config和web.config，多年以来我们已经习惯了将结构化的配置定义在这两个文件之中。到了.NET Core的时代，很多我们习以为常的东西都发生了改变，其中也包括定义配置的方式。总的来说，新的配置系统显得更加轻量级，并且具有更好的扩展性，其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源，也可以直接配置定义在持久化的文件甚至数据库中。 阅读全文

摘要： 之前写了一系列关于.NET Core/ASP.NET Core的文章，但是大都是针对RC版本。到了正式的RTM，很多地方都发生了改变，所以我会将之前发布的文章针对正式版本的.NET Core 1.0进行改写。除此之外，我还会撰写一系列与此相关的文章，这些文章以ASP.NET Core为核心，我个人将它们分成三个主要的部分，即编程基础、支撑框架和管道详解。其中编程基础主要涉及与ASP.NET Core独特的编程模型和相关编程技巧。支撑框架则介绍支撑ASP.NET Core的多个独立的框架，比如依赖注入、配置模型、配置管理等等。至于最后一部分管道详解，我们会介绍ASP.NET Core最为核心的部分，即用以处理请求的管道 阅读全文

摘要： ASP.NET Core的核心是通过一个Server和若干注册的Middleware构成的管道，不论是管道自身的构建，还是Server和Middleware自身的实现，以及构建在这个管道的应用，都需要相应的服务提供支持，ASP.NET Core自身提供了一个DI容器来实现针对服务的注册和消费。换句话说，不只是ASP.NET Core底层框架使用的服务是由这个DI容器来注册和提供，应用级别的服务的注册和提供也需要以来这个DI容器，所以正如本文标题所说的——学习ASP.NET Core，你必须了解无处不在的“依赖注入”。 阅读全文

摘要： 2016年6月27日，这是一个特殊的日子，微软全新的.NET开发平台.NET Core的RTM版本正式发布。我个人将.NET Core的核心特性归结为三点，它们的首字母组成一个非常好记的简称——COM，分别代表的含义Cross-Platform、Open-Source和Modularization。开发.NET Core应用的方式与之前具有非常大的变化，对于那些尚未体验过.NET Core的朋友，我希望通过本篇文章创建的这一个Hello World应用可以很容易地带你们入门。 阅读全文

摘要： 对于.NET开发人员来说，我们已经习惯了VS这个世界上最强大的IDE，所以对他们来说，项目的创建直接利用安装到VS中相应的项目模板即可。当.NET Core跨出了Windows的围栏，正式拥抱其他平台，意味着VS已经不再是唯一的IDE。于此同时，.NET Core充分借鉴了目前非常流行的基于“脚手架（Scaffolding）”的源文件生成方式，在它的核心命令行“dotnet”也添加了脚手架的命令行开关。除此之外，.NET Core真正对社区敞开胸怀，我们可以直接利用现有的脚手架工具Yeoman来生成.NET Core项目。接下来我们就来介绍一下两种生成.NET Core项目的方式。 阅读全文

摘要： 我们在上面对ASP.NET Core默认提供的具有跨平台能力的KestrelServer进行了详细介绍（《聊聊ASP.NET Core默认提供的这个跨平台的服务器——KestrelServer》），为了让读者朋友们对管道中的Server具有更加深刻的认识，接下来我们采用实例演示的形式创建一个自定义的Server。这个自定义的Server直接利用HttpListener来完成针对请求的监听、接收和响应，我们将其命名为HttpListenerServer。在正式介绍HttpListenerServer的设计和实现之前，我们先来显示一下如何将它应用到 一个具体的Web应用中。 阅读全文

摘要： 跨平台是ASP.NET Core一个显著的特性，而KestrelServer是目前微软推出了唯一一个能够真正跨平台的Server。KestrelServer利用一个名为KestrelEngine的网络引擎实现对请求的监听、接收和响应。KetrelServer之所以具有跨平台的特质，源于KestrelEngine是在一个名为libuv的跨平台网络库上开发的。 阅读全文

摘要： Server是ASP .NET Core管道的第一个节点，负责完整请求的监听和接收，最终对请求的响应同样也由它完成。Server是我们对所有实现了IServer接口的所有类型以及对应对象的统称，这个接口具有一个只读属性Features返回描述自身特性集合的FeatureCollection对象，另一个Start方法用于启动服务器。 阅读全文

摘要： ASP.NET Core管道虽然在结构组成上显得非常简单，但是在具体实现上却涉及到太多的对象，所以我们在 《ASP.NET Core管道深度剖析[共4篇]》 中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在这个系列 中，我们会还原构建模拟管道时可以舍弃和改写的部分，想读者朋友们呈现一个真是的HTTP请求处理管道。 ASP.NET Core 的请求处理管道由一个Server和一组有序排列的中间件构成，前者仅仅完成基本的请求监听、接收和响应的工作，请求接收之后和响应之前的所有工作都交给注册的中间件来完成。ASP.NET Core的中间件通过一个类型Func 阅读全文

摘要： 当我们利用LoggerFactory创建一个Logger对象并利用它来实现日志记录，这个过程会产生一个日志消息，日志消息的流向取决于注册到LoggerFactory之上的LoggerProvider。说的更加具体一点，日志消息的归宿取决于注册到LoggerFactory的LoggerProvider究竟会提供怎样的Logger。微软提供了一系列原生的LoggerProvider，我们先来认识一下将控制台作为日志输出目的地的ConsoleLoggerProvider 阅读全文

摘要： 除了在源代码层面实现共享（“前.NET Core时代”如何实现跨平台代码重用 ——源文件重用）之外，我们还可以跨平台共享同一个程序集，这种独立于具体平台的“中性”程序集通过创建一种名为“可移植类库（PCL： Portable Class Library）”项目来实现。为了让读者朋友们对PCL的实现机制具有充分的认识，我们先来讨论一个被我称为“程序集动态绑定”的话题。 阅读全文

摘要： 对于包括Mono在内的各个.NET Framework平台的BCL（Basic Class Library）来说，虽然在API定义层面上存在一些共同之处，但是由于它们定义在不同的程序集之中，所以在PCL（Portal Class Library）推出之前，针对程序集的共享是不可能实现的，我们只能在源代码层面实现共享。源代码的共享通过在不同项目（针对不同.NET Framework平台）之间共享源文件的方式来实现，至于具体采用的方式，我们有三种不同的方案供你选择。 阅读全文

摘要： NET Core的日志模型主要由三个核心对象构成，它们分别是Logger、LoggerProvider和LoggerFactory。总的来说，LoggerProvider提供一个具体的Logger对象将格式化的日志消息写入相应的目的地，但是我们在编程过程中使用的Logger对象则由LoggerFactory创建，这个Logger利用注册到LoggerFactory的LoggerProvider来提供真正具有日志写入功能的Logger，并委托后者来记录日志。 阅读全文

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

摘要： Uploading files is a common requirement in web applications. In ASP.NET Core 1.0 uploading files and saving them on the server is quite easy. To that end this article shows how to do just that.Begin by creating a new ASP.NET Core project. Then add HomeController to the controllers folder. Then add UploadFiles view to Views > Home folder of the application. 阅读全文

摘要： 之所以称ASP.NET Core是一个Web开发平台，源于它具有一个极具扩展性的请求处理管道，我们可以通过这个管道的定制来满足各种场景下的HTTP处理需求。ASP. NET Core应用的很多特性，比如路由、认证、会话、缓存等，也同时定制消息处理管道来实现的。我们甚至可以通过管道定制在ASP.NET Core平台上创建我们自己的Web框架，实际上MVC和SingalR这两个重要的Web框架也是采用这样的方式创建的。 阅读全文

摘要： 在《管道是如何处理HTTP请求的？》中，我们对ASP.NET Core的请求处理管道的构成以及它对请求的处理流程进行了详细介绍，接下来我们需要了解的是这样一个管道是如何被构建起来的。这样一个管道由一个服务器和一个HttpApplication构成，前者负责监听请求并将接收的请求传递给给HttpAppkication对象处理，后者则将请求处理任务委托给注册的中间件来完成。 阅读全文

摘要： 我们知道ASP.NET Core请求处理管道由一个服务器和一组有序的中间件组成，所以从总体设计来讲是非常简单的，但是就具体的实现来说，由于其中涉及很多对象的交互，我想很少人能够地把它弄清楚。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造了一个“模拟管道”并在此管道上开发了一个发布图片的应用，这篇文章旨在为你讲述管道是如何处理HTTP请求的 阅读全文

摘要： 如果想非常深刻地认识ASP.NET Core的请求处理管道，可以分两个步骤来进行，我们首先可以在忽略细节的前提下搞清楚管道处理HTTP请求的总体流程，然后再此基础上补充之前遗漏的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造了一个“模拟管道”。 阅读全文

摘要： 之所以称ASP.NET Core是一个Web开发平台，源于它具有一个极具扩展性的请求处理管道，我们可以通过这个管道的定制来满足各种场景下的HTTP处理需求。ASP. NET Core应用的很多特性，比如路由、认证、会话、缓存等，也同时定制消息处理管道来实现的。我们甚至可以通过管道定制在ASP.NET Core平台上创建我们自己的Web框架，实际上MVC和SingalR这两个重要的Web框架也是采用这样的方式创建的。 阅读全文

摘要： So, you installed .NET Core RC2 , you followed the getting started tutorial and you got your “Hello World!” printed on your command prompt just by using the CLI. Then you went the next step and you tried to use Visual Studio Code and the C# extension to edit the application outside of Visual Studio. And finally you want to try and debug and set a breakpoint inside the application, but you encountered some pr 阅读全文

摘要： 今天写了一个简单的.NET Core RC2控制台程序，发现中文显示一直是乱码。查看操作系统设置，没有问题；查看源文件编码，也没有问题；甚至查看了Console字符编码相关的注册表，依然没有发现问题。难道NET Core到了RC2，莫非连一些常用的编码都不支持吗？ 阅读全文

摘要： 在.NET Core 1.0.0 RC2即将正式发布之际，我也应应景，针对RC2 Preview版本编写一个史上最简单的MVC应用。由于VS 2015目前尚不支持，VS Code的智能感知尚欠火候，所以我们直接采用最原始的记事本来编写这个MVC应用。 阅读全文

摘要： 提到“配置”二字，我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影，那就是我们再熟悉不过的app.config和web.config，多年以来我们已经习惯了将结构化的配置信息定义在这两个文件之中。到了.NET Core的时候，很多我们习以为常的东西都发生了改变，其中也包括定义配置的方式。总的来说，新的配置系统显得更加轻量级，并且具有更好的扩展性，其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源，也可以直接配置定义在持久化的文件甚至数据库中。 阅读全文

摘要： Microsoft has decided after the RTM of the ASP.NET Core framework to phase out project.json and use MSBuild for build data. They’ve not decided whether to keep the NuGet dependencies in a pared down project.json (maybe renamed to nuget.json) or whether to just allow for a command-line action like “nuget install dependency --save” to mirror what other package managers do. 阅读全文

摘要： Exciting times lie ahead for .NET developers. During Build, Microsoft’s biggest developer event of the year, clear roadmaps were given on the future of .NET and C#. Microsoft is re-positioning .NET to be a platform that can be written anywhere and run anywhere, which is a departure from it’s long history of proprietary technologies. 阅读全文

摘要： 本节所谓的“配置同步”主要体现在两个方面：其一，如何监控配置源并在其变化的时候自动加载其数据，其目的是让应用中通过Configuration对象承载的配置与配置源的数据同步；其二、当Configuration对象承载的配置放生变换的时候如何向应用程序发送通知，最终让应用程序使用最新的配置。 阅读全文

摘要： Whether you have already drawn insights from our (free) 2016 .NET Developer Community Report or not, you will likely find this new slice of the results delicious. This infographic presents a few interesting cross-sections of data from our 2016 .NET Developer Survey, some of which are not included in the report. 阅读全文

摘要： ConfigurationBuilder在生成以Configuration对象的时候会利用注册其中的ConfigurationProvider加载原始的配置数据，那么一旦配置源中的数据发生变化，应用程序中的使用的配置信息如何与之同步呢？如果需要在应用程序中实现对配置信息的实施同步，就需要对原始配置数据的进行监控，并在数据改变的时候重新加载配置数据。除此之外，重新加载的配置需要应用到程序中，我们必然需要一种通知机制。 阅读全文

摘要： ASP.NET Core在启动以及后续针对每个请求的处理过程中的各个环节都需要相应的组件提供相应的服务，为了方便对这些组件进行定制，ASP.NET通过定义接口的方式对它们进行了“标准化”，我们将这些标准化的组件称为服务，ASP.NET在内部专门维护了一个DI容器来提供所需的服务 阅读全文

摘要： 我们在上篇和中篇对配置模型中默认提供的各种ConfigurationProvider进行了深入详尽的介绍，如果它们依然不能满足项目中的配置需求，我们可以还可以通过自定义ConfigurationProvider来支持我们希望的配置来源。就配置数据的持久化方式来说，将配置存储在数据库中应该是一种非常常见的方式，接下来我们就是创建一个针对数据库的ConfigurationProvider，它采用最新的Entity Framework 7来完成数据库的存取操作。 阅读全文

摘要： 我们在本篇文章中会介绍三种针对物理文件的ConfiguationProvider，它们分别是针对JSON文件的JsonConfiguationProvider，针对XML文件的XmlConfiguationProvider以及针对INI文件的IniConfiguationProvider。对于这三种文件类型（JSON、XML和INI）来说，JSON能够采用简单直观的格式表示具有不同结构的数据，所以它是作为配置最好的选择。 阅读全文