构成HostBuilderContext上下文的两个核心对象（表示配置的IConfiguration对象和表示承载环境的IHostEnvironment对象）可以直接注入Startup构造函数中进行消费。由于ASP.NET Core应用中的承载环境通过IWebHostEnvironment接口表示，IWebHostEnvironment接口派生于IHostEnvironment接口，所以也可以通过注入IWebHostEnvironment对象的方式得到当前承载环境相关的信息。
C#具有一个默认开启的代码分析规则：[CA1810]Initialize reference type static fields inline，推荐我们以内联的方式初始化静态字段，而不是将初始化放在静态构造函数中。
HostingEnvironment是承载应用当前执行环境的描述，它是对所有实现了IHostingEnvironment接口的所有类型以及对应对象的统称。如下面的代码片段所示，一个HostingEnvironment对象承载的执行环境的描述信息体现在定义这个接口的6个属性上。ApplicationName和EnvironmentName分别代表当前应用的名称和执行环境的名称。WebRootPath和ContentRootPath是指向两个根目录的路径，前者指向的目录用于存放可供外界通过HTTP请求访问的资源
在对ASP.NET Core管道中关于依赖注入的两个核心对象（ServiceCollection和ServiceProvider）有了足够的认识之后，我们将关注的目光转移到编程层面。在ASP.NET Core应用中基于依赖注入的编程主要涉及到两个方面，它们分别是将服务注册到ServiceCollection中，和采用注入的方式利用ServiceProvider提供我们所需的服务。我们先来讨论ASP.NET Core应用中如何进行服务注册。[本文已经同步到《ASP.NET Core框架揭秘》之中] 目录 一
《服务注册》、《服务消费》和《生命周期》主要从实现原理的角度对.NET Core的依赖注入框架进行了介绍，接下来更进一步，看看该框架的总体设计和实现。在过去的多个版本更迭过程中，依赖注入框架的底层实现一直都在发生改变，加上底层的涉及的大都是内容接口和类型，所以我们不打算涉及太过细节的层面。
我们都知道CPU和内存是程序最为重要的两类指标，那么有多少人真正想过这个问题：一个类型（值类型或者引用类型）的实例在内存中究竟占多少字节？我们很多人都回答不上来。其实C#提供了一些用于计算大小的操作符和API，但是它们都不能完全解决我刚才提出的问题。本文提供了一种计算值类型和引用类型实例所占内存字节数量的方法。源代码从这里下载。
我们都知道CPU和内存是程序最为重要的两类指标，那么有多少人真正想过这个问题：一个类型（值类型或者引用类型）的实例在内存中究竟占多少字节？我们很多人都回答不上来。
我们倾向于将IConfiguration对象转换成一个具体的对象，以面向对象的方式来使用配置，我们将这个转换过程称为配置绑定。除了将配置树叶子节点配置节的绑定为某种标量对象外，我们还可以直接将一个配置节绑定为一个具有对应结构的符合对象。除此之外，配置绑定还支持针对数据、集合和字典类型的绑定。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
虽然应用程序可以直接利用通过IConfigurationBuilder对象创建的IConfiguration对象来提取配置数据，但是我们更倾向于将其转换成一个POCO对象，以面向对象的方式来使用配置，我们将这个转换过程称为配置绑定。配置绑定可以通过如下几个针对IConfiguration的扩展方法来实现，这些扩展方法都定义在NuGet包“Microsoft.Extensions.Configuration.Binder”中。
《老生常谈：值类型 V.S. 引用类型》中花了很大的篇幅介绍ref参数针对值类型和引用类型变量的传递。在C#中，除了方法的ref参数，我们还有很多使用ref关键字传递引用/地址的场景，本篇文章作一个简单的总结。
ASP.NET Core应用中的路由机制实现在RouterMiddleware中间件中，它的目的在于通过路由解析为请求找到一个匹配的处理器，同时将请求携带的数据以路由参数的形式解析出来供后续请求处理流程使用。但是具体的路由解析功能其实并没有直接实现在RouterMiddleware中间件中，而是由一个Router对象来完成的。[本文已经同步到《ASP.NET Core框架揭秘》之中] 目录 一、IRouter接口 二、RouteContext 三、RouteData 四、Route 五、RouteHan
ASP.NET Core应用中的路由机制实现在RouterMiddleware中间件中，它的目的在于通过路由解析为请求找到一个匹配的处理器，同时将请求携带的数据以路由参数的形式解析出来供后续请求处理流程使用。但是具体的路由解析功能其实并没有直接实现在RouterMiddleware中间件中，而是由一个Router对象来完成的。
.NET利用ArrayPoolPool<T>和MemoryPool<T>提供了针对Array/Memory<T>的对象池功能。最近在一个项目中需要使用到针对字节数组的对象池，由于这些池化的字节数组相当庞大，我希望将它们分配到POH上以降低GC的压力。由于ArrayPoolPool<T>没法提供支持，所以我提供了一个极简的实现。
由于Options模型涉及的核心对象最终都注册为相应的服务，所以从原则上讲这些对象都是可以定制的，下面提供几个这样的实例。由于Options模型提供了针对配置系统的集成，所以可以采用配置文件的形式来提供原始的Options数据，可以直接采用反序列化的方式将配置文件的内容转换成Options对象。
上文说到Unmanaged、BufferedBinary和BufferedString是NativeBuffering支持的三个基本数据类型，其实我们也可以说NativeBuffering只支持Unmanaged和IReadOnlyBufferedObject<T>两种类型，BufferedString、NativeBuffering和通过Source Generator生成的BufferedMessage类型，以及下面介绍的几种集合和字典类型，都实现了IReadOnlyBufferedObject<T>接口。
包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。服务注册就是创建出现相应的ServiceDescriptor对象并将其添加到指定IServiceCollection集合对象中的过程。
通过《利用容器提供服务》我们知道作为依赖注入容器的IServiceProvider对象是通过调用IServiceCollection接口的扩展方法BuildServiceProvider创建的，IServiceCollection对象是一个存放服务注册信息的集合。在《一个迷你版DI框架》中创建的Cat框架中的服务注册是通过类型ServiceRegistry表示的，在.NET Core依赖注入框架中，与之对应的类型是ServiceDescriptor。
接触到一个老的项目，里面大量使用OleDbConnection进行数据库操作，在执行SQL块语句时，对它的顺序参数、命名参数很不了解。据说不能使用命名参数，但我这里试验了一下，好像是可以的，只是对参数的顺序还是有要求。看看你能知道下面的输出结果吗？
与服务注册一样，针对配置的设置同样可以采用三种不同的编程模式。第一种是利用WebApplicationBuilder的Host属性返回的IHostBuilder对象，它可以帮助我们设置面向宿主和应用的配置。IWebHostBuilder接口上面同样提供了一系列用来对配置进行设置的方法，我们可以将这些方法应用到WebApplicationBuilder的WebHost属性返回的IWebHostBuilder对象上。不过还是那句话，既然推荐使用Mininal API，最好还是采用最新的编程方式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
现在直播平台由于弹幕的存在，主播与观众可以更轻松地进行互动，非常受年轻群众的欢迎。斗鱼TV就是一款非常流行的直播平台，弹幕更是非常火爆。看到有不少主播接入 弹幕语音播报器、 弹幕点歌等模块，这都需要首先连接斗鱼弹幕。
上一章介绍了经过路由的处理，一个请求找到了具体处理这个请求的EndPoint，并最终执行它的RequestDelegate方法来处理这个Httpcontext。本章继续这个处理进程，按照惯例，依然通过几幅图来聊一聊这个RequestDelegate之后的故事。在此就避免不了的聊到各种Filter，它方便我们在action执行的前后做一些 “小动作”。（ASP.NET Core 系列目录）
AOP的本质是方法拦截（将针对目标方法调用劫持下来，进而执行执行的操作），置于方法拦截的实现方案，不外乎两种代码注入类型，即编译时的静态注入和运行时的动态注入，本篇文章列出了几种常用的动态注入方案。这篇文章的目标并不是提供完整的AOP框架的解决方案，而是说明各种解决方案后面的原理，所以我们提供的实例代码会尽可能简单。为了确定拦截操作是否执行，我们定义了如下这个Indicator类型，我们的拦截操作会将其静态属性Injected属性设置为True，我们演示的代码最终通过这个属性来确定拦截是否成功。[源代码从这里下载]
AOP的本质是方法拦截（将针对目标方法调用劫持下来，进而执行执行的操作），置于方法拦截的实现方案，不外乎两种代码注入类型，即编译时的静态注入和运行时的动态注入，本篇文章列出了几种常用的动态注入方案。
我们再简单回顾一下数组对象的内存布局。如下图所示，对于32位（x86）系统，Object Header和TypeHandle各占据4个字节；但是对于64位（x64）来说，存储方法表指针的TypeHandle自然扩展到8个字节，但是Object Header依然是4个字节，为了确保TypeHandle基于8字节的内存对齐，所以会前置4个字节的“留白（Padding）”。
我在面试的时候经常会问一个问题：“谈谈值类型和引用的区别”。对于这个问题，绝大部分人都只会给我两个简洁的答案：“值类型分配在栈中，引用类型分配在堆中”，“在默认情况下，值类型参数传值（拷贝），引用类型参数传引用”。其实这个问题有很大的发挥空间，如果能够从内存布局、GC、互操作、跨AppDomain传递等方面展开，相信会加分不少。这篇文章独辟蹊径，从“变量”的角度讨论值类型和引用类型的区别。
在.NET 6中，微软加入了JSON Node，可以让我们动态编辑一个JSON文档，就像Newtonsoft.Json里的JToken一样，我们就可以更加灵活的操作JSON文档。 这次主要新增的API如下表：
基于IHostBuilder/IHost的服务承载系统建立在依赖注入框架之上，它在服务承载过程中依赖的服务（包括作为宿主的IHost对象）都由代表依赖注入容器的IServiceProvider对象提供。在定义承载服务时，也可以采用依赖注入方式来消费它所依赖的服务。作为依赖注入容器的IServiceProvider对象能否提供我们需要的服务实例，取决于相应的服务注册是否预先添加到依赖注入框架中。服务注册可以通过调用IHostBuilder接口或者IWebHostBuilder接口相应的方法来完成，前者在《服务承载系统》已经有详细介绍，下面介绍基于IWebHostBuilder接口的服务注册。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
我们在前面对配置模型中默认提供的各种IConfigurationSource实现类型进行了深入详尽的介绍，如果它们依然不能满足项目中的需求，我们还可以通过自定义IConfigurationSource实现类型来支持我们希望的配置源。就配置数据的持久化方式来说，将配置存储在数据库中应该是一种常见的方式。接下来我们会创建一个针对数据库的IConfigurationSource实现类型，它采用Entity Framework Core来完成数据库的存取操作。
如今的应用部署逐渐向微服务化发展，导致一个完整的事务往往会跨越很多的应用或服务，出于分布式链路跟踪的需要，我们往往将从上游服务获得的跟踪请求报头无脑地向下游服务进行转发。本文介绍的这个名为HeaderForwarder的组件可以帮助我们完成针对指定HTTP请求报头的自动转发。本篇文章分为上下两篇，上篇通过三个例子介绍HeaderForwarder的应用场景，下篇则介绍该组件的设计与实现。[源代码从这里下载]
之前一个项目涉及到针对海量（千万级）实时变化数据的计算，由于对性能要求非常高，我们不得不将参与计算的数据存放到内存中，并通过检测数据存储的变化实时更新内存的数据。存量的数据几乎耗用了上百G的内存，再加上它们在每个时刻都在不断地变化，所以每时每刻都无数的对象被创建出来（添加+修改），同时无数现有的对象被“废弃”（删除+修改）。这种情况针对GC的压力可想而知，所以每当进行一次2代GC的时候，计算的耗时总会出现“抖动”。为了解决这类问题，几天前尝试着创建了一个名为NativeBuffering的框架。目前这个框架远未成熟，而且是一种“时间换空间”的解决方案，虽然彻底解决了内存分配的问题，但是以牺牲数据读取性能为代价的。这篇文章只是简单介绍一下NativeBuffering的设计原理和用法，并顺便收集一下大家的建议。[本文演示源代码从这里下载]
实际上，为了避免二叉树形状向最坏情况靠拢， 通常会创建能够自平衡的 2-3 树。 而 红黑树 是 2-3 树比较简单的一种实现形式：
目录 1. ObsoleteAttribute 2. 设置默认值属性： DefaultValueAttribute 3. DebuggerBrowsableAttribute 4. ？？运算符 5. Curry 及 Partial 方法 6. WeakReference 7. Lazy 8. BigInteger 9. 非官方关键字：__arglist __reftype __makeref __refvalue 10. Environment.NewLine 11. ExceptionDispatch
为了帮助大家更深刻地认识Dora.Interception，并更好地将它应用到你的项目中，我们通过如下几个简单的实例来演示几个常见的AOP应用在Dora.Interception下的实现。对于下面演示的实例，它们仅仅是具有指导性质的应用，所以我会尽可能地简化，如果大家需要将相应的应用场景移植到具体的项目开发中，需要做更多的优化。源代码从这里下载。 目录 一、对输入参数的格式化 二、对参数的自动化验证 三、对方法的返回值进行自动缓存 一、对输入参数的格式化 我们有一些方法对输入参数在格式上由一些要求，但是我们
在一个采用依赖注入框架的应用中，我们一般不太推荐利用手工创建的HttpClient对象来进行HTTP调用，使用的HttpClient对象最好利用注入的IHttpClientFactory工厂来创建。前者引起的问题，以及后者带来的好处，将通过如下这几个演示程序展现出来。IHttpClientFactory类型由“Microsoft.Extensions.Http”这个NuGet包提供，“Microsoft.NET.Sdk.Web”SDK具有该包的默认引用。如果采用“Microsoft.NET.Sdk”这个SDK，需要添加该包的引用。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
毫不夸张地说，整个ASP.NET Core框架是建立在一个依赖注入框架之上的，它在应用启动时构建请求处理管道过程中，以及利用该管道处理每个请求过程中使用到的服务对象均来源于DI容器。该DI容器不仅为ASP.NET Core框架提供必要的服务，同时作为了应用的服务提供者，依赖注入已经成为了ASP.NET Core应用基本的编程模式。在前面一系列的文章中，我们主要从理论层面讲述了依赖注入这种设计模式，补充必要的理论基础是为了能够理解与ASP.NET Core框架无缝集成的依赖注入框架的设计原理。我们总是采用“先简单体验，后者深入剖析”来讲述每一个知识点，所以我们利用一些简单的实例从编程层面来体验一下服务注册的添加和服务实例的提取。
样例中的扫雷实现主要是两个类型(BombGame 和 BombGrid),下面是完整代码:
在 OpenXML 的颜色画刷填充，有特殊的填充是 GrpFill 属性，对应 OpenXML SDK 定义的 DocumentFormat.OpenXml.Drawing.GroupFill 类型
毫不夸张地说，整个ASP.NET Core就是建立在依赖注入框架之上的。ASP.NET Core应用在启动时构建管道所需的服务，以及管道处理请求使用到的服务，均来源于依赖注入容器。依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务，还为应用程序提供服务，依赖注入已经成为ASP.NET Core应用的基本编程模式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
VBA写的再熟练的人，一般也很难做到一次性就写出完美无错的代码，总会有一些考虑不周全的情况或者单词写错而导致的程序出错，特别是新手，出错的可能就更加的高了。
本文是我在读 WPF 源代码做的笔记。在 WPF 中的 AppDomainShutdownMonitor 类是一个不开放的类，这个类当前只是给 D3DImage 类使用。在 AppDomainShutdownMonitor 提供了在应用的进程或程序域关闭的时候，进行一次通知，当前是用来清理 D3DImage 类的资源
毫无疑问，字符串是我们使用频率最高的类型。但是如果我问大家一个问题：“一个字符串对象在内存中如何表示的？”，我相信绝大部分人回答不上来。我们今天就来讨论这个问题。
我们在《聊聊默认支持的各种配置源》和《深入了解三种针对文件（JSON、XML与INI）的配置源》对配置模型中默认提供的各种ConfigurationSource进行了深入详尽的介绍，如果它们依然不能满足项目中的配置需求，我们可以还可以通过自定义ConfigurationProvider来支持我们希望的配置来源。就配置数据的持久化方式来说，将培植存储在数据库中应该是一种非常常见的方式，接下来我们就是创建一个针对数据库的ConfigurationSource，它采用最新的Entity Framework Cor
ASP.NET Core框架建立在一个依赖注入框架之上，已注入的方式消费服务已经成为了ASP.NET Core基本的编程模式。为了使读者能够更好地理解原生的注入框架框架，我按照类似的设计创建了一个简易版本的依赖注入框架，并它命名为“Cat”。本篇提供的四个实例主要体现了针对Cat的用法，《一个Mini版的依赖注入框架》提供了针对设计和实现原理的介绍。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
一个对象总是映射一块连续的内存序列（不考虑对象之间的引用关系），如果我们知道了引用类型实例的内存布局，以及变量引用指向的确切的地址，我们不仅可以采用纯“二进制”的方式在内存“绘制”一个指定引用类型的实例，还能直接通过改变二进制内容来更新实例的状态。
游戏开发中,我们一般都要进行大量的对象更新(Update)操作,拿 Unity 中的 MonoBehavior 举例,其便支持定义专门的 Update 方法来处理相关 Component 的更新:
前一篇文章主要介绍了.NET Core继承Kestrel的目的、运行方式以及相关的使用，接下来将进一步从源码角度探讨.NET Core 3.0中关于Kestrel的其他内容，该部分内容，我们无需掌握，依然可以用好Kestrel，本文只是将一些内部的技术点揭露出来，供自己及大家有一个较深的认识。
表达式树是 .net 中一系列非常好用的类型。在一些场景中使用表达式树可以获得更好的性能和更佳的扩展性。本篇我们将通过构建一个 “模型验证器” 来理解和应用表达式树在构建动态调用方面的优势。
毫不夸张地说，整个ASP.NET Core框架是建立在依赖注入框架之上的。ASP.NET Core应用在启动时构建管道以及利用该管道处理每个请求过程中使用到的服务对象均来源于依赖注入容器。该依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务，同时也是应用程序的服务提供者，依赖注入已经成为了ASP.NET Core应用的基本编程模式。
最近在阅读 .NET Core Runtime 的源码，参考大佬的代码，学习编写技巧和提高代码水平。学习过程中将学习心得和值得应用到项目中的代码片段记录下来，供日后查阅。
当我们使用System.Text.Json.JsonSerializer对一个字典对象进行序列化的时候，默认情况下字典的Key不能是一个自定义的类型，本文介绍几种解决方案。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
