.net core有三种部署方式
依赖框架部署FDD、独立部署SCD、依赖框架的可执行文件FDE
1.依赖框架部署FDD==>使用场景较多
依赖系统已安装的.net core库(运行时，SDK)，只包含自己的代码和第三方的依赖项。
包含.dll文件
操作步骤：
第一步，选择程序，右键发布，选择文件发布
第二步：更多操作/编辑
优点：
不必预先定义应用运行的目标操作系统，生成的可执行文件和库，是通用的PE文件格式，.net core都可执行，
部署包比较小，自己的代码和第三方的依赖项、降低磁盘空间、如果运行时更新--只需更新操作系统
缺点：
系统上的.net core版本必须和应用目标的.net core版本一样或高于
2.独立部署SCD==>单独、独立
不依赖系统的.net core,自己的代码和第三方依赖项，还包含.net core库，独立，同时还包括一个可执行文件.exe
优点：
可以单独控制与应用一起部署的.net core版本
可以保证应用是能够运行的
缺点：
不可移植，必须选择应用的目标系统
部署包比较大
注：不同版本.net core对系统有要求，win10一般都支持
3.依赖框架的可执行文件FDE==>
针对系统优化，一般应用不多
注：
部署到IIS，有两种方式
1.进程内托管
进程管理器(IIS、Windows服务)：收到请求的时候启用应用，并且在应用发生故障的时候负责重启。
2.进程外托管
通过反向代理将请求转发给应用
注：有什么区别？
进程内比进程外性能要高，进程外，多了一层转发，环回适配器(网络接口，用于将传出的网络流程返回给同一个计算机，Kestrel,这里也有性能的损失)；
Kestrel功能比较弱，不应该直接把Kestrel暴露出去
NGINX只有进程外托管，代理服务器
发布后会生成Web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\WebApplication1.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
hostingModel——设置部署到IIS方式：
1.hostingModel="inprocess" ——启用IIS
2.hostingModel="outofprocess"——启用Kestrel
部署前更改部署IIS方式
选择项目双击并添加配置项，如下图所示：
