当我们将原有ASP.NET 应用程序升级迁移到ASP.NET Core之后,我们发现代码工程中多了两个类Program类和Startup类。
在本篇博客中,我将描述与之前版本相比,ASP.NET Core 3.0 中已经被标记为废弃的类型。我将解释一下为什么这些类型被废弃了,它们的替换类型是什么,以及你应该什么时候使用它们。
ASP.NET Core应用本质上就是一个由中间件构成的管道,承载系统将应用承载于一个托管进程中运行起来,其核心任务就是将这个管道构建起来。从设计模式的角度来讲,“管道”是构建者(Builder)模式最典型的应用场景,所以ASP.NET Core先后采用的三种承载方式都是采用这种模式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》)
ASP.NET Core应用本质上就是一个由中间件构成的管道,承载系统将应用承载于一个托管进程中运行起来,其核心任务就是将这个管道构建起来。在ASP.NET Core的发展历史上先后出现了三种应用承载的编程方式,而且后一种编程模式都提供了针对之前编程模式的全部或者部分兼容,这就导致了一种现象:相同的更能具有N种实现方式。对这个发展历程不是特别了解的读者会有很多疑问?为什么这么多不同的编程模式都在作同一件事?它们之间的有什么差别之处?为什么有的API在最新的Minimal API又不能用了呢?[本文部分内容来源于《ASP.NET Core 6框架揭秘》第15章]
【五分钟的dotnet】是一个利用您的碎片化时间来学习和丰富.net知识的博文系列。它所包含了.net体系中可能会涉及到的方方面面,比如C#的小细节,AspnetCore,微服务中的.net知识等等。 5min+不是超过5分钟的意思,"+"是知识的增加。so,它是让您花费5分钟以下的时间来提升您的知识储备量。
ASP.NET Core框架目前存在两个承载(Hosting)系统。ASP.NET Core最初提供了一个以IWebHostBuilder/IWebHost为核心的承载系统,其目的很单纯,就是通过下图所示的形式承载以服务器和中间件管道构建的Web应用。ASP.NET Core 3依然支持这样的应用承载方式,但是本系列不会涉及这种“过时”的承载方式。
趁着假期的时间所以想重新学习下微软的官方文档来巩固下基础知识。我们都知道微软目前已经发布了.NET Core3.0的第三个预览版,同时我家里的电脑也安装了vs2019。So,就用vs2019+.NET Core3.0来跟着做一下Contoso University这个WEB应用,但是在基于3.0进行操作的时候遇到了一些问题,所以我就查看了微软的《从 ASP.NET Core 迁移 2.2 到 3.0 预览版 2》这篇文档,就着今天遇到的问题,所以我整理下,希望对大伙有所帮助,当然大伙也可以直接阅读微软的官方文档进行查看。但是我在阅读官方说明的时候,总感觉翻译的不是很准确,读起来很拗口,所以这里我是自己的理解对官方文档的一个补充。
我们直接利用Visual Studio 打开前面这个helloworld.csproj项目文件。为了能够使用ASP.NET Core 框架提供的程序集,我们可以通过修改项目文件(.csproj)添加针对“Microsoft.AspNetCore.App”的框架引用(FrameworkReference)。在Visual Studio中修改项目文件非常方便,我们只需要右键选择目标项目,并从弹出的菜单中选择“Edit Project File”就可以了。如下所示的是修改后的项目文件,针对“Microsoft.AspNetCore.App”的框架引用被添加到<ItemGroup/>节点下。
基于IHostBuilder/IHost的承载系统通过IHostEnvironment接口表示承载环境,我们利用它不仅可以得到当前部署环境的名称,还可以获知当前应用的名称和存放内容文件的根目录路径。对于一个Web应用来说,我们需要更多的承载环境信息,额外的信息定义在IWebHostEnvironment接口中。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
要承载一个ASP.NET Core应用,只需要将GenericWebHostService服务注册到承载系统中即可。但GenericWebHostService服务具有针对其他一系列服务的依赖,所以在注册该承载服务之前需要先完成对这些依赖服务的注册。针对GenericWebHostService及其依赖服务的注册是借助GenericWebHostBuilder对象来完成的。
[接上篇]“天下大势,分久必合,合久必分”,ASP.NET应用通过GenericWebHostService这个承载服务被整合到基于IHostBuilder/IHost的服务承载系统中之后,也许微软还是意识到Web应用和后台服务的承载方式还是应该加以区分,于是推出了基于WebApplicationBuilder/WebApplication的承载方式。我们可以将其称为第三代承载模式,它有一个官方的名称叫做“Minimal API”。Minimal API同样面临向后兼容的问题,而且这次需要同时兼容前面两代承载模式,所以我们会发现“上篇”中提到的一系列初始化操作有了更多实现方式。[本文部分内容来源于《ASP.NET Core 6框架揭秘》第15章]
理解 dotNET Core 中的管道模型,对我们学习 dotNET Core 有很大的好处,能让我们知其然,也知其所以然,这样在使用第三方组件或者自己写一些扩展时,可以避免入坑,或者说避免同样的问题多次入坑。
P5第2段 原文:由于创建的是一个针对 ASP.NET Core 的可执行控制台应用,所以将 OutputType 和 TargetFramework 的属性分别设置为“Exe”和“net6.0”。 改为:由于创建的是一个针对 .NET 6的可执行控制台应用,所以将 OutputType 和 TargetFramework 的属性分别设置为“Exe”和“net6.0”。 P7第2段 原文:由于创建的是 ASP.NET Core 的应用程序,所以最终生成的程序集被保存在“\bin\Debug\net6.0\
基于IHostBuilder/IHost的服务承载系统建立在依赖注入框架之上,它在服务承载过程中依赖的服务(包括作为宿主的IHost对象)都由代表依赖注入容器的IServiceProvider对象提供。在定义承载服务时,也可以采用依赖注入方式来消费它所依赖的服务。作为依赖注入容器的IServiceProvider对象能否提供我们需要的服务实例,取决于相应的服务注册是否预先添加到依赖注入框架中。服务注册可以通过调用IHostBuilder接口或者IWebHostBuilder接口相应的方法来完成,前者在《服务承载系统》已经有详细介绍,下面介绍基于IWebHostBuilder接口的服务注册。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
通过《服务承载系统[2]: 承载长时间运行的服务[下篇]》的介绍可知,IHostBuilder接口中定义了ConfigureHostConfiguration方法和ConfigureAppConfiguration方法,它们可以帮助我们设置面向宿主(IHost对象)和应用(承载服务)的配置。针对配置的初始化也可以借助IWebHostBuilder接口来完成。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
ASP .NET Core中的通用主机构建器是在v2.1中引入的,应用在启动时构建主机,主机作为一个对象用于封装应用资源以及应用程序启动和生存期管理。其主要功能包括配置初始化(包括加载配置以及配置转换为通用的键值对格式),创建托管环境和Host通用上下文、依赖注入等。
1. 引言 对于ASP.NET Core应用程序来说,我们要记住非常重要的一点是:其本质上是一个独立的控制台应用,它并不是必需在IIS内部托管且并不需要IIS来启动运行(而这正是ASP.NET Core跨平台的基石)。ASP.NET Core应用程序拥有一个内置的Self-Hosted(自托管)的Web Server(Web服务器),用来处理外部请求。 不管是托管还是自托管,都离不开Host(宿主)。在ASP.NET Core应用中通过配置并启动一个Host来完成应用程序的启动和其生命周期的管理(如下图所示
Minimal API仅仅是在基于IHost/IHostBuilder的服务承载系统上作了小小的封装而已,它利用WebApplication和WebApplicationBuilder这两个类型提供了更加简洁的API,同时提供了与现有API的兼容。要成分理解Minimal API的实现原理,得先对服务承载系统有基本的理解,对此不了解的可以参阅《服务承载模型[上篇]》、《服务承载模型[下篇]》、《承载服务启动流程[上篇]》和《承载服务启动流程[下篇]》。对于本篇提供的模拟代码,可以从这里下载。
与服务注册一样,针对配置的设置同样可以采用三种不同的编程模式。第一种是利用WebApplicationBuilder的Host属性返回的IHostBuilder对象,它可以帮助我们设置面向宿主和应用的配置。IWebHostBuilder接口上面同样提供了一系列用来对配置进行设置的方法,我们可以将这些方法应用到WebApplicationBuilder的WebHost属性返回的IWebHostBuilder对象上。不过还是那句话,既然推荐使用Mininal API,最好还是采用最新的编程方式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》)
一个ASP.NET Core应用的核心就是由一个服务器和一组有序中间件组成的请求处理管道,服务器只负责监听、接收和分发请求,以及最终完成对请求的响应,所以一个ASP.NET Core应用针对请求的处理能力和处理方式由注册的中间件来决定。一个ASP.NET Core在启动过程中的核心工作就是注册中间件,本节主要介绍应用启动过程中以中间件注册为核心的初始化工作。
在这个特殊的春节,大家想必都在家出不了门,远看已经到了回城里上班的日子,但是因为一只蝙蝠的原因导致我们无法回到工作岗位,大家可能有的在家远程办公,有些在家躺着看书,有的是在家打游戏;在这个特殊无聊的日子,从无聊的被窝中 开启了流量共享wifi 来进行.net core 3.1 源代码的解读和学习,并且把学习到的东西分享给大家。
开发.NET Core应用,直接映入眼帘的就是Startup类和Program类,它们是.NET Core应用程序的起点。通过使用Startup,可以配置化处理所有向应用程序所做的请求的管道,同时也可以减少.NET应用程序对单一服务器的依赖性,使我们在更大程度上专注于面向多服务器为中心的开发模式。
通用Host(Generic Host) 与 web Host 不同的地方就是通用Host解耦了Http请求管道,使得通用Host拥有更广的应用场景。比如:消息收发、后台任务以及其他非http的工作负载。这些场景都可以通过使用通用Host拥有横切(Cross-cutting)的能力,比如:配置、依赖注入和日志记录。 ***
上篇文章我给大家讲解了ASP.NET Core的概念及为什么使用它,接着带着你一步一步的配置了.NET Core的开发环境并创建了一个ASP.NET Core的mvc项目,同时又通过一个实战教你如何在页面显示一个Content的列表。不知道你有没有跟着敲下代码,千万不要做眼高手低的人哦。这篇文章我们就会设计一些复杂的概念了,因为要对ASP.NET Core的启动及运行原理、配置文件的加载过程进行分析,依赖注入,控制反转等概念的讲解等。俗话说,授人以鱼不如授人以渔,所以文章旨在带着大家分析源码,让大家能知其然更能知其所以然。为了偷懒,继续使用上篇文章的例子了!有兴趣的朋友可以加群637326624相互交流! 再次感谢张队的审稿!
上篇文章我给大家讲解了ASP.NET Core的概念及为什么使用它,接着带着你一步一步的配置了.NET Core的开发环境并创建了一个ASP.NET Core的mvc项目,同时又通过一个实战教你如何在页面显示一个Content的列表。不知道你有没有跟着敲下代码,千万不要做眼高手低的人哦。这篇文章我们就会设计一些复杂的概念了,因为要对ASP.NET Core的启动及运行原理、配置文件的加载过程进行分析,依赖注入,控制反转等概念的讲解等。俗话说,授人以鱼不如授人以渔,所以文章旨在带着大家分析源码,让大家能知其然更能知其所以然。为了偷懒,继续使用上篇文章的例子了!有兴趣的朋友可以加群637326624相互交流!
本文需要您了解ASP.NET Core Web API 和 xUnit的相关知识.
在本视频中,我们将讨论ASP.NET Core 项目中appsettings.json文件的重要性。
作为.NET程序员我们都清楚如何修改.NET Web程序上传文件的大小,但是我最近在做.NET Core 项目的时候发现我不清楚如何修改Kestrel上传文件的大小,经过翻阅微软官方文档我成功实现了修改Kestrel上传文件大小的。现特分享出来给大伙儿。 在 Net Core 中默认 body 最大是28.6M,如果要修改这个大小,有两种方法,一种是局部修改,另一种是全局修改,下面我分别来说一下。
•http://localhost:5000•https://localhost:5001
ASP.NET Core 应用程序启动时,它首先会配置并运行其宿主,宿主主要用来启动、初始化应用程序,并管理其生命周期
ASP.NET Core设计初衷是开源跨平台、高性能Web服务器,其中跨平台特性较早期ASP.NET是一个显著的飞跃,.NET现可以理直气壮与JAVA同台竞技,而ASP.NET Core的高性能特性更是成为致胜法宝。
ASP.NET Core源码的学习,我们从Hosting开始, Hosting的GitHub地址为:https://github.com/aspnet/Hosting.git 朋友们可以从以上链接克隆
"跨平台"后的ASP.Net Core是如何接收并处理请求的呢? 它的运行和处理机制和之前有什么不同? 本章从"宏观"到"微观"地看一下它的结构以及不同时期都干了些什 本章主要内容如下: ASP.NE
此处以一个Web API 项目为例, 针对不太大的项目,采用了一个划分为三层的结构。
"跨平台"后的ASP.Net Core是如何接收并处理请求的呢? 它的运行和处理机制和之前有什么不同? 本章从"宏观"到"微观"地看一下它的结构以及不同时期都干了些什么. ASP.NET Core
.NET Core 3.0 即将在本月的.NET Conf大会上发布正式版,在这之前包括我在内的不少朋友已经迫不及待使用预览版迁移了自己的应用,并爆得体无完肤。好在从Preview 7开始,API已经固定,可以当作正式版的内容去学习。今天我介绍的就是 Azure Application Insights 这块的迁移技巧。
上一篇文章介绍了如何将开发好的 Asp.Net Core 应用程序部署到 IIS,且学习了进程内托管和进程外托管的区别;接下来就要说说应用 Asp.Net Core 的特性(跨平台),将 .NetCore 部署到 Linux 中,主流的 Linux 有多个版本的操作系统,这里以 Centos-7.5 为例子,其它版本的操作系统下的部署基本都是大同小异的,除了了一些命令上的区别。
ASP.NET Core 应用默认监听的端口是 5000 , 在调试或者部署的过程中经常需要指定监听的端口来来运行, 本文就这个问题, 进行一个总结, 可以通过下面的方法来指定运行端口。
从ASP.NET 2.0开始最大请求正文大小限制为30MB (+28.6 MiB)。在正常情况下,无需增加 HTTP 请求 body 的大小。但是,当您尝试上传大型文件 (> 30MB) 时,需要增加默认允许的最大限制。在这篇简短的文章中,我们将了解如何在.netcore 应用程序中增加文件 ASP.NET 大小以及控制此限制的各种选项。
首先,打开VS2019新建一个ASP.NET Core Web Api项目,项目创建好后会有一个集成好的天气预报的类和控制器,接下来,我们的方法就在天气控制器里完成。
ASP.NET Core项目为开发人员提供了面向 .NET Core 和/或 .NET Framework 的灵活性。 若要确定最合适的目标框架,请参阅《从.NET Framework迁移到.NET Core/.NET5的技术指南》。
简单整理了 ASP.NET Core 从1.0到5.0的变迁,不包括小版本, 内容主要来自 MS Docs。
用于配置应用程序启动时必要的配置,比如应用程序启动时所需要监听的端口,URL 地址
最近一两个星期,加班,然后回去后弄自己的博客,把自己的电脑从 Windows 10 改到 Ubuntu 18.10 又弄回 Windows 10,原本计划的学习 Vue 中生命周期的相关知识目前也没有任何的进展,嗯,罪过罪过。看了眼时间,11月也快要结束了,准备补上一篇如何将我们的 .NET Core 2.0 版本的程序升级到 .NET Core 2.1 版本,好歹也算多学了一点。
在ASP.NET Core项目中,我们有一个名为Program.cs的文件。在这个文件中,我们有一个public static void Main()方法 。
在进行 Web 项目开发的过程中,可能会存在一些需要经常访问的静态数据,针对这种在程序运行过程中可能几乎不会发生变化的数据,我们可以尝试在程序运行前写入到缓存中,这样在系统后续使用时就可以直接从缓存中进行获取,从而减缓因为频繁读取这些静态数据造成的应用数据库服务器的巨大承载压力。
经过一段时间的学习,终于来到了部署服务这个环节,.NetCore 的部署方式非常的灵活多样,但是其万变不离其宗,所有的 Asp.NetCore 程序都基于端口的侦听,在部署的时候仅需要配置侦听地址、端口(一个或者多个)即可,在掌握好其托管部署原理后,剩下的就是对托管宿主的选择,通过本文,希望可以带给大家一种清晰的部署思路,选择最适合自己的服务部署方式。
NLog是一个基于.NET平台编写的日志记录类库,我们可以使用NLog在应用程序中添加极为完善的跟踪调试代码。可以在任何一种.NET语言中输出带有上下文的(contextual information)调试诊断信息,根据喜好配置其表现样式之后发送到一个或多个输出目标(target)中。
ASP.NET Core 3增加了一个非常有意思的功能Worker Service.他是一个ASP.NET Core模板,他允许我们创建托管长期的运行的后台服务,这些服务具体实现IHostedService接口的后台任务逻辑,他被成为"托管服务".同时他们可以部署到windows中Windows服务,以及Linux守护程序.
领取专属 10元无门槛券
手把手带您无忧上云