通过 nuget 安装 UEditorNetCore
从 UEditor 官网 下载最新的包 ueditorx_x_x_x-utf8-net.zip
解压包，并复制到项目的 wwwroot/lib 目录下，删除 net 目录。
根据 UEditorNetCore 官方的使用说明进行操作
步骤中，控制器 UEditorController 接替原 controller.ashx 的功能，用于统一处理上传逻辑
原 config.json 复制到项目根目录，用于配置上传相关设置（若更改文件名和路径在 services.AddUEditorService() 中处理）。
个人喜欢将 xxxPathFormat 值改为：upload/ueditor/{yyyy}{mm}{dd}/{time}{rand:6}，方便日后迁移附件后进行批量替换。
记得配置 catcherLocalDomain 项。
上传相关的身份验证和授权控制请在 UEditorController 中处理，如：
public void Do()
{
if (用户未登录) { throw new System.Exception("请登录后再试"); }
_ue.DoAction(HttpContext);
}如果图片仅仅上传到网站目录下，那么这样配置就结束了，如果要上传到阿里云 OSS 等第三方图床，那么继续往下看。
因 UEditorNetCore 虽然实现了上传到 FTP 和 OSS 的功能，但未提供配置相关的账号信息的途径，所以只能（1）重写 action，或（2）下载 github 的源代码，将核心项目加入到您的项目中进行修改。
重写 action 不方便后期维护，这里记录修改源码的方式。
将源码改造为可配置账号的上传到 OSS 的功能，具体步骤如下：
将 Consts.cs 从项目中排除。
打开 Handlers/UploadHandler.cs，找到 UploadConfig 类，将
FtpUpload 改为 OssUpload，
FtpAccount 改为 OssAccessKeyId，
FtpPwd 改为 OssAccessKeySecret，
FtpIp 改为 OssAccessEndpoint，
再添加一个属性 OssBucketName。
打开 Handlers/UploadHandler.cs，找到 Process() 方法，
将 UploadConfig.FtpUpload 改为 UploadConfig.OssUpload，
将 Consts.AliyunOssServer.* 改为 UploadConfig.Oss*。
打开 Handlers/CrawlerHandler.cs，找到 Fetch() 方法，
将 Config.GetValue<bool>("catcherFtpUpload") 改为 Config.GetValue<bool>("OssUpload")，
将 Consts.AliyunOssServer.* 改为 Config.GetString("Oss*")。
打开 UEditorActionCollection.cs，找到 UploadImageAction，将
FtpUpload = Config.GetValue<bool>("imageFtpUpload"), FtpAccount = Consts.ImgFtpServer.account, FtpPwd = Consts.ImgFtpServer.pwd, FtpIp = Consts.ImgFtpServer.ip,替换为
OssUpload = Config.GetValue<bool>("OssUpload"), OssAccessKeyId = Config.GetString("OssAccessKeyId"), OssAccessKeySecret = Config.GetString("OssAccessKeySecret"), OssAccessEndpoint = Config.GetString("OssAccessEndpoint"), OssBucketName = Config.GetString("OssBucketName"),其余 3 个 Action（UploadScrawlAction、UploadVideoAction、UploadFileAction）按同样的方式修改。
在所有创建 UploadHandler 对象时补充添加 SaveAbsolutePath 属性。
打开 config.json，添加相关配置项（注：配置文件中的 *FtpUpload 全部废弃，统一由 OssUpload 决定）
"OssUpload": true, "OssAccessEndpoint": "", "OssAccessKeyId": "", "OssAccessKeySecret": "", "OssBucketName": "",将 xxxUrlPrefix 的值改为 OSS 对应的 CDN 网址（以 / 结尾，如：//cdn.xoyozo.net/）。
其它注意点：
若使用 UEditorNetCore github 提供的源代码类库代替 nuget，且使用本地存储，那么需要将 Handlers 目录中与定义 savePath 相关的代码（查找 var savePath）替换成被注释的行
ueditor.all.min.js: Uncaught DOMException: Blocked a frame with origin "http://localhost:4492" from accessing a cross-origin frame.
at baidu.editor.ui.Dialog.close
当引用第三方 CDN 静态资源的方式部署百度编辑器时，使用多图上传、涂鸦等功能（弹出框使用 iframe 标签引用 CDN 上的网页）会报上述跨域错误。
官方并没有给出这种部署方案（即客户端页面与页面之间的 iframe 跨域）的完美跨域方法。
但官方针对服务端和客户端分离的跨域情形进行了说明：
按这两篇文章部署即可：
ASP.NET Core 缓存（Cache）之 Redis 缓存
ASP.NET Core 会话状态（Session State）
存储内容示例：
图中，
第 1 项为浏览器 A 中，在 Session 中设置键 count 值为 1 的结果；
第 2 项为浏览器 B 中，在 Session 中设置键 count 值为 3 的结果；
而第 3 项为设置 Cache 键 count 值为 8 的结果。
按这两篇文章部署即可：
ASP.NET Core 缓存（Cache）之 SQL Server 缓存
ASP.NET Core 会话状态（Session State）
存储内容示例：
图中，
第 1 项为浏览器 A 中，在 Session 中设置键 count 值为 3 的结果；
第 3 项为浏览器 B 中，在 Session 中设置键 count 值为 1 的结果；
而第 2 项为设置 Cache 键 count 值为 5 的结果。
本文环境：CentOS 7、nginx 1.16、ASP.NET Core 3.0
安装 nginx，可以使用宝塔面板。
创建网站，保证网站静态页面能够正常访问。
必要时配置 SSL 证书。
安装 ASP.NET Core 运行时：
安装说明见：https://dotnet.microsoft.com/download，切换到 Linux，选择 Install .NET Core Runtime
选择操作系统，按页面说明安装即可。
发布一个 ASP.NET Core 项目到网站目录，运行应用程序：
dotnet 应用的程序集文件名.dll必须先 cd 到项目所在目录再执行，否则“Content root path”不会指向网站根目录，从而导致无法访问静态文件。
观察到端口为 5000（默认），该 Url 用于下一步设置反向代理。
配置 nginx 反向代理：（使用宝塔面板时建议使用面板中提供的“反向代理”功能）
location / { proxy_pass http://localhost:5000; }查看官方详细说明：使用 Nginx 在 Linux 上托管 ASP.NET Core
本文介绍 ASP.NET 的 Swagger 部署，若您使用 ASP.NET Core 应用程序，请移步 ASP.NET Core Web API Swagger 官方文档：
https://github.com/domaindrivendev/Swashbuckle.AspNetCore
安装
NuGet 中搜索安装 Swashbuckle，作者 Richard Morris
访问
http://您的域名/swagger
配置
显示描述
以将描述文件（xml）存放到项目的 bin 目录为例：
打开项目属性，切换到“生成”选项卡
在“配置”下拉框选择“所有配置”
更改“输出路径”为：bin\
勾选“XML 文档文件”：bin\******.xml，（默认以程序集名称命名）
打开文件：App_Start/SwaggerConfig.cs
取消注释：c.IncludeXmlComments(GetXmlCommentsPath());
添加方法：
public static string GetXmlCommentsPath() { return System.IO.Path.Combine( System.AppDomain.CurrentDomain.BaseDirectory, "bin", string.Format("{0}.xml", typeof(SwaggerConfig).Assembly.GetName().Name)); }其中 Combine 方法的第 2 个参数是项目中存放 xml 描述文件的位置，第 3 个参数即以程序集名称作为文件名，与项目属性中配置一致。
如遇到以下错误，请检查第 2、3、4 步骤中的配置（Debug / Release）
500 : {"Message":"An error has occurred."} /swagger/docs/v1使枚举类型按实际文本作为参数值（而非转成索引数字）
打开文件：App_Start/SwaggerConfig.cs
取消注释：c.DescribeAllEnumsAsStrings();
这是一篇可能解决困扰了 .NET 程序猿多年的文章！
首先，使用 Visual Studio 2019 创建一个 ASP.NET WEB 应用程序，直接选用了 MVC 模板。
直接发布项目，默认的设置如下图：
对于小型项目，按默认设置发布基本可满足正常运行，首次运行打开第一个页面基本在 5~6 秒（视服务器配置），其它页面的首次打开也基本在 1~2 秒完成，非首次瞬间打开。
一旦项目功能变得复杂，文件增多，会导致发布后首次运行打开第一个页面 30 秒以上，其它页面的首次打开 10 秒左右，非首次瞬间打开。
这是因为项目在发布时没有进行预编译，而是在用户访问网页时动态编译，一旦应用程序池回收，或项目文件改动，都会重新编译，再次经历缓慢的“第一次”，这是不能忍的。
于是咱们来研究一下“预编译”。
在发布页面勾选“在发布期间预编译”，这时发布会在“输出”窗口显示正在执行编译命令（编译时间会比较长）：
该选项对发布后的文件结构和内容影响不大，因此对首次执行效率的提升也不大，重要的在后面。
在“高级预编译设置”窗口中：
我们针对预编译选项和合并选项分别做测试。
不勾选“允许更新预编译站点”，会致 bin 目录中生成许多 .compiled 文件，而所有 .cshtml 文件的内容都是：
这是预编译工具生成的标记文件，不应删除!
如果是 Web From 网站，.aspx/.ashx 等文件内容同上。
尝试打开网站页面，你会发现，除了项目启动后的第一个页面仍然需要 1~2 秒（无 EF），其余每个页面的首次都是瞬间打开的（EF 的首次慢不在本文讨论范围）。这让我对预编译有一种相见恨晚的感觉！
这里偷偷地告诉你，把 Views 目录删掉也不影响网页正常打开哦~为什么不让删，咱也不敢问，咱也不敢删。
目的达到了，有一些后遗症需要解决，比如 bin 目录内杂乱无章。
选“不合并。为每个页面和控件创建单独的程序集”，结果是 bin 多出许多 App_Web_*.dll 文件。
选“将所有输出合并到单个程序集”，填写程序集名称。这时会发现“输出”窗口执行了命令：
如果程序集名称跟已有名称冲突，会发生错误：
合并程序集时出错: ILMerge.Merge: The target assembly '******' lists itself as an external reference.
查看 bin 目录，.compiled 文件还在，但 App_Web_*.dll 合并成了一个程序集。FTP 的“不合并”也是把所有 App_Web_*.dll 上传一遍，所以不存在相对于“合并”的增量发布优势。
是不是勾了“视为库组件删除(AppCode.compiled 文件)”.compiled 文件就会不见？意外之外，情理之中，bin 没有什么变化。
继续选择“将各个文件夹输出合并到其自己的程序集”，呃，bin 中文件数不降反增。
最后选择“将所有页和控件输出合并到单个程序集”，同样程序集名称不能冲突。结局令人失望，bin 中仍然一大堆 .compiled 和 App_Web_*.dll。
整理成表格：
| 1 | 允许更新预编译站点 aspnet_compiler.exe -v / -p \Source -u \TempBuildDir 重复发布后 bin 目录文件数：不会增多（页面不进行预编译） |
| 2 | 不允许更新预编译站点，不合并 aspnet_compiler.exe -v / -p \Source \TempBuildDir 重复发布后 bin 目录文件数：.compiled 不会增多，App_Web_*.dll 增多 |
| 3 | 不允许更新预编译站点，不合并。为每个页面和控件创建单独的程序集 aspnet_compiler.exe -v / -p \Source -c -fixednames \TempBuildDir 重复发布后 bin 目录文件数：不会增多（编译后的文件名固定，FTP 方式的部分 App_Web_*.dll 文件可能实现增量上传） |
| 4 | 不允许更新预编译站点，将所有输出合并到单个程序集，不勾选“视为库组件” aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数：不会增多（.compiled 固定名称，App_Web_*.dll 合并为一个） |
| 5 | 不允许更新预编译站点，将所有输出合并到单个程序集，勾选“视为库组件” aspnet_compiler.exe -v / -p \Source \TempBuildDir aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a -r 重复发布后 bin 目录文件数：不会增多（.compiled 固定名称，App_Web_*.dll 合并为一个） |
| 6 | 不允许更新预编译站点，将每个文件夹输出合并到其自己的程序集，前缀 aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -prefix 前缀 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数：.compiled 不会增多，App_Web_*.dll 增多 |
| 7 | 不允许更新预编译站点，将所有页和控件输出合并到单个程序集 aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -w 程序集名称 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数：.compiled 不会增多，App_Web_*.dll 增多 |
bin 目录下，页面的程序集文件（App_Web_*.dll）增多的原因是编译后的文件名不固定，发布到会导致残留许多无用的程序集文件。
相比较，如果第 3 种能实现 FTP 稳定的增量上传的话是比较完美的（还有一个缺点是：如果页面有删除，目标 bin 内对应该页面的 .compiled 和 .dll 不会删除，这跟“允许更新预编译站点”是一个情况），那么第 4 种 或第 5 种也是不错的选择（同样有缺点：执行合并比较慢）。
测试一个有 300 个页面的项目，compiler 用时约 2 分钟，merge 用时约 5 分钟，发布用时约 4 分钟。
这里有个槽点，执行预编译和合并是佛系的，CPU 和磁盘使用率永远保持在最低水平。
所以如果是要经常修改的项目，那么建议选择“不合并”的第 3 种发布方式：
“视为库组件（删除 AppCode.compiled 文件）”：移除主代码程序集（App_Code 文件夹中的代码）的 .compiled 文件。 如果应用程序包含对主代码程序集的显式类型引用，则不要使用此选项。
补充：
不允许更新预编译站点发布后，因为前端页面没有内容，因此无法单独修改发布（单独发布一个页面后，在访问时不会生效！），只能全站发布，耗时较长；bin 目录有变动将导致使用 InProc 方式存储的 Session 丢失。
预编译的另一个优点是可以检查 .aspx / .cshtml 页面 C# 部分的错误（特别是命名空间和路径引用）。
改为预编译发布后，可以将服务器上残留的 .master / .ascx / .asax 删除，但不能删除 .aspx / .ashx /.config 等。
VS 发布到 FTP 经常会遗漏一些页面文件，不合并时会遗漏独立文件，合并后也会遗漏合并后的 .dll 的文件，合并的好处就是方便检查是否完全上传发布。
慎选“在发布前删除所有现有文件”！一旦勾选发布，世界就清静了，所有网友上传的图片附件以及网站运行产生的其它文件，消失得无影无踪。不管发布到文件系统还是发布到 FTP 都一样。当然，如果是先发布到文件系统，再通过 FileZilla 等 FTP 软件上传到服务器的，建议勾选此项。
.NET Core 应用程序部署：https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index
由于上传文件时 bin 目录文件较多，理论上 bin 目录内的文件有任何改动都会重启应用池，而且 VS 是单线程上传的，导致期间网站访问缓慢，服务器 CPU 升高，我的做法是：发布到文件系统，再使用专用 FTP 工具上传，上传用时约半分钟（如果大小不同或源文件较新则覆盖文件）。还嫌慢？那就打包上传，解压覆盖。
关于本文研究对象的官方解释：高级预编译设置对话框
出现“未能加载文件或程序集“***”或它的某一个依赖项。试图加载格式不正确的程序。”的问题时，先用改用 Debug 方式发布会报详细错误，一般是 .aspx 等客户端页面有 C# 语法问题，注意提示报错的是 /obj/ 目录下的克隆文件，应更改原文件。排除错误后关闭所有页面，再使用 Release 方式发布。
2025年9月补充：因预编译发布后生成的文件时间都是系统最新时间，通过 FTP 上传到服务器时都会覆盖文件，可能导致杀毒软件进程 MsMpEng.exe 占用 CPU 过高。尝试选择不进行预编译，即取消“发布期间预编译”前的勾，这样发布的的文件时间都是文件本身的最后修改时间，重复发布不会更新这个时间，而且 bin 目录中也不会出现大量编译后的文件。这样通过 FTP 上传时只要设置“大小不同且文件较新则覆盖”就不会重复上传文件了，杀毒软件的工作量就能大大减少。缺点就是本文开头说的，每个页面的第一次打开会比较慢，而是非常慢。所以仍然需要勾选“发布期间预编译”，同时勾上“允许更新预编译站点”，这样 bin 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
Font Awesome 从 5.0 版本开始，在保持经典的 Web Fonts with CSS 外，还提供更现代化，功能更强大的 SVG with JS 部署方式。
升级为 SVG with JS 后，如果部分图标不显示，可能的原因是：
· 部分在老版本中的图标不再 5.0 版本上提供，解决的方法是引用 fa-v4-shims.js；
· 此方式把 <i /> 标签通过 JS 替换为 <svg /> 标签，须要改动 CSS 样式。
如果仍然使用 Web Fonts with CSS，部分图标不显示，可能的原因是：
· 新版本不再推荐以 fa 的 class 引用，对 Solid（实心）、Regular（标准）、Light（简洁）、Brands（品牌）四大分类分别使用新的命名方式：fas、far、fal、fab。具体可以在 Font Awesome 官网上找到相应图标后，点击打开图标详情，复制已经生成的 HTML 代码。fa 将被视为 fas。
Session 有多种存储模式，默认是 InProc，顾名思义是“在进程内”，即在 IIS 中，随网站重启而重启，网站发布后（或改动 .dll 文件）会导致应用重新运行，Session 清空。
Session 可以使用 StateServer 来保存，需要服务器开启 ASP.NET State Service 服务，此种方式要求保存在 Session 的信息必须序列化，然后从 Session 中获取的时候也要反序列化，这就导致性能有略微的损失。
Session 还可以配置为 SQLServer，将 Session 存储在数据库中，同样需要序列化。
当配置为 Custom 时，可以在使用 Memcached、Redis 等第三方缓存技术来实现 Session 的管理，本文不作讨论。
Off 模式即关闭 Session，这种方式如果要实现用户登录功能，就必须依赖 Cookie 等来实现。
下面针对常见的三种模式进行比较：
| InProc | StateServer | SQLServer | |
| 存储位置 | 应用进程内 | ASP.NET State Service 服务 | SQL Server 数据库 |
| 远程存储 | 不支持 | 支持 | 支持 |
| 存储格式 | 任意 | 序列化的 | 序列化的 |
| 可能导致重启（丢失）的情况 | 配置文件中 processModel 标签的 memoryLimit 属性； Global.asax 或者 Web.config 文件被更改； Bin 文件夹中的 Web 程序（DLL）被修改； 杀毒软件扫描了一些 .config 文件； 系统资源紧张进行资源回收导致 IIS 进程崩溃或重启等。 | ASP.NET State Service 服务停止； | - |
| Session_End() 事件 | 有 | 无 | 无 |
| 部署难度 | 无 | 简单 | 稍复杂 |
Web.config 配置示例 （<system.web> 节点内） | <sessionState mode="InProc" /> | <sessionState mode="StateServer" /> | <sessionState mode="SQLServer" sqlConnectionString ="data source=x.x.x.x; user id=[user]; password=[pwd]" /> |
因此，如果你仅仅为了标题所述的“每次发布后丢失 Session”而烦恼，那么推荐使用 StateServer 模式来存储 Session。
注：
如果 Session 的 Key 是在应用启动时随机生成的话，使用 StateServer 和 SQLServer 还是会“丢失” Session。
这是对 Session 的配置，对 Cache 无效。
上一篇介绍了如何创建用于 https 的 SSL 证书，本文讲述如何将创建好的 SSL 证书配置到 nginx 中。
导入证书
将 .key 文件和 .crt 文件上传到服务器，位置如：/etc/ssl/
配置 .conf
打开网站配置文件 *.conf，一般在 /usr/local/nginx/conf/vhost/
添加监听 443 端口：
listen 443 ssl;添加 ssl 配置信息：
ssl_certificate /etc/ssl/yourdomain.com.crt;
ssl_certificate_key /etc/ssl/yourdomain.com.key;
ssl_prefer_server_ciphers on;yourdomain.com.crt 和 yourdomain.com.key 改成真实的文件名
实现 http 自动跳转 https
配置非 443 端口请求跳转 443 端口访问：
if ($server_port !~ 443)
{
rewrite ^(/.*)$ https://$host$1 permanent;
}如果要求仅将 GET/HEAD 请求自动跳转（POST 请求自动跳转会丢失表单数据），那么改成：
set $redirect_https 0;
if ($server_port !~ 443)
{
set $redirect_https 1;
}
if ($request_method ~ ^(GET|HEAD)$)
{
set $redirect_https "${redirect_https}2";
}
if ($redirect_https = 12)
{
rewrite ^(/.*)$ https://$host$1 permanent;
}验证
最后来检查一下配置得对不对：https://www.geocerts.com/ssl_checker
扩展阅读