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

 

转载于:https://www.cnblogs.com/Codemandyk/p/10901414.html