.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方式
选择项目双击并添加配置项,如下图所示: