最近在把自己的一个老项目从Framework迁移到.Net Core 3.0，数据访问这块选择的是EFCore+Mysql。使用EF的话不可避免要和DbContext打交道，在Core中的常规用法一般是：创建一个XXXContext类继承自DbContext，实现一个拥有DbContextOptions参数的构造器，在启动类StartUp中的ConfigureServices方法里调用IServiceCollection的扩展方法AddDbContext，把上下文注入到DI容器中，然后在使用的地方通过构造函数的参数获取实例。OK，没任何毛病，官方示例也都是这么来用的。但是，通过构造函数这种方式来获取上下文实例其实很不方便，比如在Attribute或者静态类中，又或者是系统启动时初始化一些数据，更多的是如下一种场景：
这是该系列的第二篇文章：在ASP.NET Core 3.0中使用Serilog.AspNetCore。
《呈现错误信息》通过几个简单的实例演示了如何呈现一个错误页面，该过程由3个对应的中间件来完成。下面先介绍用来呈现开发者异常页面的DeveloperExceptionPageMiddleware中间件，该中间件在捕捉到后续处理过程中抛出的异常之后会返回一个媒体类型为text/html的响应，后者在浏览器上会呈现一个错误页面。由于这是一个为开发者提供诊断信息的异常页面，所以可以将其称为开发者异常页面（Developer Exception Page）。该页面不仅会呈现异常的详细信息（类型、消息和跟踪堆栈等），还会出现与当前请求相关的上下文信息。如下所示的代码片段是DeveloperExceptionPageMiddleware中间件的定义。更多关于ASP.NET Core的文章请点这里]
基于IHostBuilder/IHost的承载系统通过IHostEnvironment接口表示承载环境，我们利用它不仅可以得到当前部署环境的名称，还可以获知当前应用的名称和存放内容文件的根目录路径。对于一个Web应用来说，我们需要更多的承载环境信息，额外的信息定义在IWebHostEnvironment接口中。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
我们现在大多数转向ASP.NET Core来使用开发的团队，应该都不是从0开始搭建系统，而是老的业务系统已经在运行，ASP.NET Core用来开发新模块。那么解决用户认证的问题，成为我们的第一个拦路虎。本文将给大家简单阐述一下认证与授权的基本概念，以及基于ASP.NET Core 中间件实现的认证和改造JwtBearer 认证中间件来实现的认证达到与老系统（主要是token-based认证）的集成。 目录 认证与授权 什么是认证 何谓授权 用Middleware拦截 定制JWT Bearer 认证 更
在《ASP.NET Core应用的错误处理[1]：三种呈现错误页面的方式》中，我们通过几个简单的实例演示了如何呈现一个错误页面，这些错误页面的呈现分别由三个对应的中间件来完成，接下来我们将对这三个中间件进行详细介绍。在开发环境呈现的异常页面是通过一个类型为DeveloperExceptionPageMiddleware中间件实现的。[本文已经同步到《ASP.NET Core框架揭秘》之中] 1: public class DeveloperExceptionPageMiddleware 2:
显而易见，一个常规的身份认证用例包括两部分： ① 对用户进行身份验证 ② 在未经身份验证的用户试图访问受限资源时作出反应
在2019年1月的微软技术（苏州）俱乐部成立大会上，蒋金楠老师（大内老A）分享了一个名为“ASP.NET Core框架揭秘”的课程，他用不到200行的代码实现了一个ASP.NET Core Mini框架，重点讲解了7个核心对象，围绕ASP.NET Core最核心的本质—由服务器和若干中间件构成的管道来介绍。我在腾讯视频上看到了这个课程的录像，看了两遍之后结合蒋金楠老师的博客《200行代码，7个对象—让你了解ASP.NET Core框架的本质》一文进行了学习并下载了源代码进行研究，然后将其改成了基于.NET Standard的版本，通过一个.NET Framework和一个.NET Core的宿主端来启动一个ASP.NET Core的Server，并将其放到了GitHub上，欢迎Clone学习。
在ASP.NET MVC中，最核心的当属“路由系统”，而路由系统的核心则源于一个强大的System.Web.Routing.dll组件。
在 ASP.NET Core 里，如果你想单元测试 HttpContext.Features.Get<SomeType>()，这个技巧一定不要错过。
在一个ASP.NET MVC应用来说，针对HTTP请求的处理和相应定义Controller类型的某个Action方法中，每个HTTP请求的目标对象不再像ASP .NET Web Form应用一样是一个物理文件，而是某个Controller的某个Action。目标Controller和Action的名称包含在HTTP请求中，而ASP.NET MVC的首要任务就是通过当前HTTP请求的解析得到正确的Controller和Action的名称。这个过程是通过ASP.NET MVC的URL路由机制来实现的。 一、Ro
当我们最开始学习一门技术的时候都喜欢从Hello World来时，貌似和我们本篇的主题不太搭。但事实却非如此，在我们看来如下这个Hello World是对ASP.NET Core框架本质最好的体现。
首先我们知道http是一种无状态的请求，他的生命周期就是从客户端浏览器发出请求开始，到得到响应结束。那么MVC应用程序从发出请求到获得响应，都做了些什么呢？ 本文我们会详细讨论MVC应用程序一个请求的生命周期，从一个控件到另一个控件是怎样被处理的。我们还会详细介绍一下整个请求的生命周期中，用到的相关组件。因为在平常的开发过程中，我们可能知道怎样去使用MVC框架来处理相关的请求，大部分的时候我们只是在controller和action方法之间做相关的处理，对于真正内在的运行机制可能不是很了解。
笔者没有学 ASP.NET，直接学 ASP.NET Core ，学完 ASP.NET Core MVC 基础后，开始学习 ASP.NET Core 的运行原理。发现应用程序有一个非常主要的 “传导体” HttpContext 。
在本篇博客中，我将描述与之前版本相比，ASP.NET Core 3.0 中已经被标记为废弃的类型。我将解释一下为什么这些类型被废弃了，它们的替换类型是什么，以及你应该什么时候使用它们。
首先我们知道http是一种无状态的请求，他的生命周期就是从客户端浏览器发出请求开始，到得到响应结束。那么MVC应用程序从发出请求到获得响应，都做了些什么呢？
相信很多读者已经看过老A写的这篇文章《200行代码，7个对象——让你了解ASP.NET Core框架的本质》，这是一篇模仿和重建的典范。重建说白了就是模仿，模仿有一个前置条件就是你对底层原理要烂熟于心。否则画虎难画骨，原本要画虎，最后出来的是只猫。
在读这篇文章之间，建议先看一下我的 ASP.NET Core 之 Identity 入门系列（一，二，三）奠定一下基础。
自定义中间件为开发人员提供了更大的灵活性和控制权，使他们能够更好地定制和优化ASP.NET Core应用程序的请求处理流程，满足特定的业务和性能需求。
在开始之前，我们需要明确的一个概念是，在 Web 程序中，用户的每次请求流程都是线性的，放在 ASP.NET Core 程序中，都会对应一个 请求管道（request pipeline），在这个请求管道中，我们可以动态配置各种业务逻辑对应的 中间件（middleware），从而达到服务端可以针对不同用户做出不同的请求响应。在 ASP.NET Core 中，管道式编程是一个核心且基础的概念，它的很多中间件都是通过 管道式 的方式来最终配置到请求管道中的，所以理解这里面的管道式编程对我们编写更加健壮的 DotNetCore 程序相当重要。
现在越来越多的人在谈论. NET Core。诚然，.NET Core 是未来, 但是.NET Framework 仍在支持, 因为大量的应用程序无法在短时间内迁移。
本文提供了 ASP.NET Core 的性能最佳实践指南。 译文原文地址：https://docs.microsoft.com/en-us/aspnet/core/performance/perfor
开篇：上一篇我们了解了一个请求从客户端发出到服务端接收并转到ASP.Net处理入口的过程，这篇我们开始探索ASP.Net的核心处理部分，借助强大的反编译工具，我们会看到几个熟悉又陌生的名词（类）：HttpRuntime、HttpWorkerRequest、HttpContext、HttpApplication等。
我们一致在说 ASP.NET Core广泛地使用到了依赖注入，通过前面两个系列的介绍，相信读者朋友已经体会到了这一点。由于前面两章已经涵盖了依赖注入在管道构建过程中以及管道在处理请求过程的应用，但是内容相对分散和零碎，我们有必要针对这个主题作一个归纳性的介绍。采用依赖注入的服务均由某个ServiceProvider来提供，但是在ASP.NET Core管道涉及到两个不同的ServiceProvider，其中一个是在管道成功构建后创建并绑定到WebHost上的ServiceProvider，对应着WebHos
在 asp.net core 中，存在着中间件这一概念，在中间件中，我们可以比过滤器更早的介入到 http 请求管道，从而实现对每一次的 http 请求、响应做切面处理，从而实现一些特殊的功能
本系列主要翻译自《ASP.NET MVC Interview Questions and Answers 》- By Shailendra Chauhan，想看英文原版的可访问http://www.dotnettricks.com/free-ebooks自行下载。该书主要分为两部分，ASP.NET MVC 5、ASP.NET WEB API2。本书最大的特点是以面试问答的形式进行展开。通读此书，会帮助你对ASP.NET MVC有更深层次的理解。 由于个人技术水平和英文水平也是有限的，因此错误在所难免，希
从 18 年开始接触 .NET Core 开始，在私底下、工作中也开始慢慢从传统的 mvc 前后端一把梭，开始转向 web api + vue，之前自己有个半成品的 asp.net core 2.2 的项目模板，最近几个月的时间，私下除了学习 Angular 也在对这个模板基于 asp.net core 3.1 进行慢慢补齐功能
因为Session的服务端存储需要缓存，所以需要引入.Net core的缓存DistributedMemoryCache；
在Membership系列的最后一篇引入了ASP.NET Identity，看到大家对它还是挺感兴趣的，于是来一篇详解登录原理的文章。本文会涉及到Claims-based（基于声明）的认证，我们会详细介绍什么是Claims-based认证，它与传统认证方式的区别，以及它的特点。同时我们还会介绍OWIN (Open Web Interface for .NET) 它主要定义了Web Server 和Web Application之间的一些行为，然后实现这两个组件的解耦（当然远不止这么点东西，我相信OWIN马
ASP.NET核心中间件组件是被组装到应用程序管道中以处理HTTP请求和响应的软件组件（从技术上来说，组件只是C＃类）。 ASP.NET Core应用程序中的每个中间件组件都执行以下任务。
2019年1月19日，微软技术（苏州）俱乐部成立，我受邀在成立大会上作了一个名为《ASP.NET Core框架揭秘》的分享。在此次分享中，我按照ASP.NET Core自身的运行原理和设计思想创建了一个 “迷你版” 的ASP.NET Core框架，并且利用这个 “极简” 的模拟框架阐述了ASP.NET Core框架最核心、最本质的东西。整个框架涉及到的核心代码不会超过200行，涉及到7个核心的对象。由于ASP.NET Core 3.X采用了不同的应用承载方式，所以我们将这个模拟框架升级到3.x版本。[本篇内容节选自即将出版的《ASP.NET Core 3框架解密》，感兴趣的朋友可以通过《“ASP.NET Core 3框架揭秘”读者群，欢迎加入》加入本书读者群，以便及时了解本书的动态。源代码从这里下载。]https://files.cnblogs.com/files/artech/mini-asp-net-core-framework.7z
2019年1月19日，微软技术（苏州）俱乐部成立，我受邀在成立大会上作了一个分享。在此次分享中，我按照ASP.NET Core自身的运行原理和设计思想创建了一个 “迷你版” 的ASP.NET Core框架，并且利用这个 “极简” 的模拟框架阐述了ASP.NET Core框架最核心、最本质的东西。整个框架涉及到的核心代码不会超过200行，涉及到7个核心的对象。由于ASP.NET Core 3.X采用了不同的应用承载方式，所以我们将这个模拟框架升级到3.x版本。[本篇内容节选自即将出版的《ASP.NET Core 3框架解密》，感兴趣的朋友可以加入本书读者群，以便及时了解本书的动态。源代码从下载。
ASP.NET Core请求处理管道由一个服务器和一组有序排列的中间件构成，所有中间件针对请求的处理都在通过HttpContext对象表示的上下文中进行。由于应用程序总是利用服务器来完成对请求的接收和响应工作，所以原始请求上下文的描述由注册的服务器类型来决定。但是ASP.NET Core需要在上层提供具有一致性的编程模型，所以我们需要一个抽象的、不依赖具体服务器类型的请求上下文描述，这就是本章着重介绍的HttpContext。[本文节选自《ASP.NET Core 3框架揭秘》第13章, 更多关于ASP.NET Core的文章请点这里]
在进行了URL Rewrite之后，经常会遇到的问题就是页面中PostBack的目标地址并非客户端请求的地址，而是URL Rewrite之后的地址。以上一篇文章中的重写为例：
正如我们在《依赖注入：控制反转》提到过的，很多人将IoC理解为一种“面向对象的设计模式”，实际上IoC不仅与面向对象没有必然的联系，它自身甚至算不上是一种设计模式。一般来讲，设计模式提供了一种解决某种具体问题的方案，但是IoC既没有一个针对性的问题领域，其自身也没有提供一种可操作性的解决方案，所以我们更加倾向于将IoC视为一种设计原则。很多我们熟悉的设计模式背后都采用了IoC原则，接下来我们就来介绍几种典型的“设计模式”。
很久没更新了，今天写点关于Asp.Net MVC的PipeLine。首先我们确认一点，Asp.Net WebFrom和Asp.Net MVC是在.Net平台下的两种web开发方式。其实他们都是基于Asp.Net Core的不同表现而已。看下面一张图，我们就能理解了WebForm和Asp.Net MVC的一个关系了。
我们前面已经讨论过了如何在一个网站中集成最基本的Membership功能，然后深入学习了Membership的架构设计。正所谓从实践从来，到实践从去，在我们把Membership的结构吃透之后，我们要完善它，改造它，这样我们才能真正学以致用。今天我们将以用户信息为主线，从SqlMembershipProvider出发，到ASP.NET Simple Membership最后再到MV5中引入的ASP.NET Identity，来看看微软是如何一步一步的改造这套框架的。 引入 - 用户信息是如何存在数据库
日志记录不仅对于我们开发的应用，还是对于ASP.NET Core框架功能都是一项非常重要的功能特性。我们知道ASP.NET Core使用的是一个极具扩展性的日志系统，该系统由Logger、LoggerFactory和LoggerProvider这三个核心对象组成。我们可以通过简单的配置实现对LoggerFactory的定制，以及对LoggerProvider添加。 目录 一、 配置LoggerFactory 二、以当前请求作为日志范围 三、记录异常日志 一、 配置LoggerFactory 我们在上面一节
在本文中，我将讲解如何通过自定义ExceptionHandlerMiddleware，以便在中间件管道中发生错误时创建自定义响应，而不是提供一个“重新执行”管道的路径。
从本篇开始将围绕asp.net core身份验证写个小系列，希望你看完本系列后，脑子里对asp.net core的身份验证原理有个大致印象。
今天不说.NET Core里的新MemoryCache（Microsoft.Extensions.Caching.Memory），说说目前用得最广泛的.NET Framework下的缓存。
我们都知道，ASP.NET Core作为最新的框架，在MVC5和ASP.NET WebForm的基础上做了大量的重构。如果我们想使用以前版本中的HttpContext.Current的话，目前是不可用的，因为ASP.NET Core中是并没有这个API的。
我们将整个ASP.NET MVC框架划分为若干个子系统，那么针对请求上下文激活目标Controller对象的子系统被我们成为Controller激活系统。在正式讨论Controller对象具体是如何被创建爱之前，我们先来看看Controller激活系统在ASP.NET MVC中的总体设计，了解一下组成该子系统的一些基本的组件，以及它们对应的接口或者抽象类是什么。 目录 一、Controller 二、 ControllerFactory 三、ControllerBuilder 实例演示：如何提
本系列文章，主要分享一些.NET Core比较优秀的社区资料和微软官方资料。我进行了知识点归类，让大家可以更清晰的学习.NET Core。
ASP.NET Core的请求处理管道由一个服务器和一组中间件构成，但对于面向传输层的服务器来说，它其实没有中间件的概念。当服务器接收到请求之后，会将该请求分发给一个处理器进行处理，对服务器而言，这个处理器就是一个HTTP应用，此应用通过IHttpApplication<TContext>接口来表示。由于服务器是通过IServer接口表示的，所以可以将ASP.NET Core框架的核心视为由IServer和IHttpApplication<TContext>对象组成的管道。[本文节选自《ASP.NET Core 3框架揭秘》第13章, 更多关于ASP.NET Core的文章请点这里]
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
