摘要： 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能够采用简单直观的格式表示具有不同结构的数据，所以它是作为配置最好的选择。 阅读全文

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

摘要： 我们在《读取配置信息》通过实例的形式演示了如何利用Options模型以依赖注入的方式直接获取由指定配置节绑定生成的Options对象，我们再次回顾一下当初我们编写的程序。如下面的代码片段所示，基于Options模型的配置绑定的编程基本采用这样的模式：先后调用ServiceCollection的扩展方法AddOption和Configure注册Options模型相关的服务并完成Options类型与指定配置节之间的映射，然后利用由此生成ServiceProvider获得一个类型为IOptions的服务示例，后者的Value就是配置绑定生成的Options对象。 阅读全文

摘要： 出于编程上的便利，我们通常不会直接利用ConfigurationBuilder创建的Configuration对象读取某个单一配置项的值，而是倾向于将一组相关的配置绑定为一个对象，我们将后者称为Options对象。我们在本章第一节通过简单的实例演示了如何利用Options模型实现了配置数据向Options对象的绑定，现在我们对Options模型背后的实现原理进行详细介绍。 阅读全文

摘要： 在上面一章我们以实例演示的方式介绍了几种读取配置的几种方式，其中涉及到三个重要的对象，它们分别是承载结构化配置信息的Configuration，提供原始配置源数据的ConfigurationProvider，以及作为“中间人”的ConfigurationBuilder。现在我们对 以这三个对象为核心的配置模型进行深入介绍。 阅读全文

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

摘要： 到目前为止，我们定义的ServiceProvider已经实现了基本的服务提供和回收功能，但是依然漏掉了一些必需的细节特性。这些特性包括如何针对IServiceProvider接口提供一个ServiceProvider对象，何创建ServiceScope，以及如何提供一个服务实例的集合。 阅读全文

摘要： 通过上一篇的介绍我们应该对实现在ServiceProvider的总体设计有了一个大致的了解，但是我们刻意回避一个重要的话题，即服务实例最终究竟是采用何种方式提供出来的。ServiceProvider最终采用何种方式提供我们所需的服务实例取决于最终选择了怎样的ServiceCallSite，而服务注册是采用的ServiceDescriptor有决定了ServiceCallSite类型的选择。我们将众多不同类型的ServiceCallSite大体分成两组，一组用来创建最终的服务实例，另一类则与生命周期的管理有关。 阅读全文

摘要： 本系列前面的文章我们主要以编程的角度对ASP.NET Core的依赖注入系统进行了详细的介绍，如果读者朋友们对这些内容具有深刻的理解，我相信你们已经可以正确是使用这些与依赖注入相关的API了。如果你还对这个依赖注入系统底层的实现原理具有好奇心，可以继续阅读这一节的内容。 阅读全文

摘要： ServiceProvider最终提供的服务实例都是根据对应的ServiceDescriptor创建的，对于一个具体的ServiceDescriptor对象来说，如果它的ImplementationInstance和ImplementationFactory属性均为Null，那么ServiceProvider最终会利用其ImplementationType属性返回的真实类型选择一个适合的构造函数来创建最终的服务实例。我们知道服务服务的真实类型可以定义了多个构造函数，那么ServiceProvider针对构造函数的选择会采用怎样的策略呢？ 阅读全文

摘要： 在采用了依赖注入的应用中，我们总是直接利用DI容器直接获取所需的服务实例，换句话说，DI容器起到了一个服务提供者的角色，它能够根据我们提供的服务描述信息提供一个可用的服务对象。ASP.NET Core中的DI容器体现为一个实现了IServiceProvider接口的对象。ASP.NET Core针对依赖注入的编程主要体现在两个方面：其一，创建一个ServiceCollection对象并将服务注册信息以ServiceDescriptor对象的形式添加其中；其二，针对ServiceCollection对象创建对应的ServiceProvider并利用它提供我们需要的服务实例。 阅读全文

摘要： IoC主要体现了这样一种设计思想：通过将一组通用流程的控制从应用转移到框架之中以实现对流程的复用，同时采用“好莱坞原则”是应用程序以被动的方式实现对流程的定制。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在上面介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更为有价值的IoC模式，即依赖注入（DI：Dependency Injection，以下简称DI）。 阅读全文