3:WebHost的默认配置


♣ 视频地址:https://www.bilibili.com/video/av38392956/?p=2

1:承接上文,继续说一下Program.cs

  1.1:这个方法使用了WebHost方法里的静态方法CreateDefaultBuilder(),这个CreateWebHostBuilder()会返回一个类型叫IWebHostBuilder

  1.2:而这个WebHostBuilder是一个对象,实现了这个接口的对象,我们暂时叫他WebHostBuilder,这个WebHostBuilder知道如何来设置WebServer的环境,包括里面的参数

  1.3:而这个CreateDefaultBuilder()进行了默认的设置,我们可以在下面写些代码来改变默认设置

 

2:首先看下默认配置的主要内容

   2.1:在ASP.NET Core里面使用了Kestrel Web服务器,这个服务器是ASP.NET Core内置的并且跨平台的,凡是ASP.NET Core支持的平台这个服务器都能在上面运行

  2.2:Kestrel Web服务器就可以监听Http请求,我们可以从命令行运行Kestrel Web Server

  2.3: 如果你安装ReSharper,就可以对CreateDefaultBuilder()这个方法进行反编译,当然了很多人是没装的,但是也有办法,如下图:

    2.3.1:选择工具,选项,文本编译器,C#,高级,支持导航到反编译(实验)把这个勾上!

   2.4:然后我们就可以对CreateDefaultBuilder()进行反编译了,在方法上F12,选择是,就可以看到源码了,下面的红框里就可以看到,使用了Kestrel Web Server

   2.5:还有一个默认配置是,我们这个应用默认使用了IIS并且使用了IIS集成,实际是两个方法,一个是UseIIS(),一个是UseIISIntegration()

    2.5.1:UseIISIntegration(),假如说我们这个应用运行于IIS服务器,那么UseIISIntegration()这个方法就允许IIS通过Windows的凭证验证来到Kestrel服务器。这对于构建内网的web应用非常有用。

    2.5.2:UseIIS()这个方法会启动.NET Core的CLR 运行时,并且把我们的web应用放在IIS Worker进程里面,这个进程要么是w3wq.exe,要么就是IIS Express.exe,这种形式就叫Inprocess 模型。与之相反的就是outofprocess,前面说过outofprocess这个模型把请求转发给或者说代理给Kestrel服务器,这种性能就没有InProcess好

  2.6:我们继续看CreateDefaultBuilder()的源码,往下拉,你会看到红框里面它先使用了UseIIS()方法,然后使用了UseIISIntegration()方法

   2.7:默认配置还有一个Log设置,直接看源码,下图

    2.7.1:还是CreateDefaultBuilder(),它配置了ConfigureLogging(),然后参数里面用Lambda表达式做了配置,比如说AddConsole().输出到控制台,AddDebug()输出到VS 输出窗口

 

   2.8:IConfiguration接口,我们这个默认的WebHostBuilde,它会创建一个对象,这个对象将实现IConfiguration这个接口,而我们可以再整个的ASP.NET Core应用里来访问这个对象

   2.9:我们可以通过IConfiguration接口从实现了他在这个接口的对象里获取我们所需要的配置信息,看源码:↓

    2.9.1:默认的WebHostBuilder是new出来的,然后进去WebHostBuilder里面去,看源码:↓    

    2.9.2:里面有个IConfiguration属性,在构造函数里进行了赋值    Configuration = _config

    2.9.3:然后进去IConfiguration里面去,看源码:↓

    2.9.4:通过索引,就可以取得配置的值,Key Value形式的

 

3:IConfiguration配置信息的来源

  ♠:appsettings.json,如果使用它,在web项目根目录下放这么一个文件,那么这个文件会立即被识别出来,因为默认配置CreateDefaultBuilder()里面使用了这个文件名,如下图,当然你使用其他的什么什么.json也可以

  

  ♣:User Secrets

  ♥:电脑的环境变量

  ♦:命令行启动参数

  ....等等,不列举那么多了

 

4:由于项目里已经有了appsetting.json,那我们就用这个了,我们现在如何把运行出现的Hello World移植到这个设置里呢,可以这么写

  4.1:如上图,在下面加一个变量Welcome,他的值是Hello World!!!!


 

  4.2:回到Startup.cs,我们需要把值读取出来,这时候我们需要使用IConfiguration,实现了该接口的一个对象,我们暂时管它叫服务configuration

  4.3:这种方式就是在这个方法的参数里请求了这么一个服务,并且这个服务是实现了IConfiguration这个接口的服务,实现了这个接口的对象,那为什么可以这么做呢?

  4.4:因为ASP.NET Core使用依赖注入,而且是在整个应用几乎所有的地方都可以使用依赖注入,所以可以这么用,它的原理如下

  4.5:原理:当ASP.NET Core调用Configure这个方法的时候,ASP.NET Core会分析这个方法的参数,目前请求这三个参数,他就会进行分析,如果ASP.NET Core能解析这些参数的类型,那么ASP.NET Core就会传进来实现该接口的对象/或者叫服务

  4.6:现在呢实现了IConfiguration的这个接口的对象已经被注入进来了,所以我们可以使用configuration来获取从appsetting.json的配置信息

  4.7:如下图所示,可以读取到appsetting.json的变量信息

 


 

  4.8:IConfiguration这个接口的配置信息源可以来自不同的地方,下面来试一下不同的地方的优先级

    4.8.1:系统环境变量,我们在系统环境变量添加一个Welcome,值是Hello From Environment Variables

    4.8.2:然后我们可以F5运行项目,看到值变成了Hello From Environment Variables,所以说系统环境变量的优先级>appsetting.json文件的优先级

    4.8.3:那么为什么系统环境变量的优先级要比appsetting.json的优先级要高?看源码:↓

     4.8.4:可以看到有个config,这个config就是IConfigurationBuilder ,首先添加了Json文件,AddJsonFile,在appsetting.json读取配置信息

     4.8.5:后面有个hostingEnvironment.EnvironmentName,什么意思呢,就是你现在是开发的环境,那么就是appsettings.Development.json,就是下图这个文件,如果这个文件存在的话,就会从这个文件读取配置信息,appsettings.Development.json的优先级>appsetting.json的优先级

     4.8.6:然后继续看源码,有个config.AddEnvironmentVariables(),就是继续加载系统的环境变量,如果系统的环境变量里存在和上面两个同样的属性信息,那么就会采用系统环境变量,也就是后加载的

     4.8.7:再往后看,有个config.AddCommandLine(args),命令行的启动参数,如果在命令行启动参数设置变量叫Welcome,那么程序最后输出的是命令行启动参数这个Welcome所对应的值

    4.8.8:综上所述,不同的配置源有相同的属性,那么后加载的配置源将会覆盖之前配置源的这个属性的值

    4.8.9:那么命令行是怎么加的呢,如图所示,可以看到,最终加载的是:Hello World From Command Line

 

posted @ 2019-05-27 22:04  大北票  阅读(1119)  评论(0编辑  收藏  举报