在 CentOS 中部署 ASP.NET Core 网站

本文环境：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

xoyozo 5 年前

5,206

ASP.NET Core 使用 DBFirst 模式连接 MySQL 数据库（Pomelo.EntityFrameworkCore.MySql）

本文使用 Pomelo 提供的 Pomelo.EntityFrameworkCore.MySql，如使用 MySql.Data.EntityFrameworkCore 请移步。

对比 MySql.Data.EntityFrameworkCore 与 Pomelo.EntityFrameworkCore.MySql

本文以 Visual Studio 2019、ASP.NET Core 3.0 开发环境为例。

新建 ASP.NET Core Web 应用程序。
安装 NuGet 包：
Microsoft.EntityFrameworkCore.Tools
Pomelo.EntityFrameworkCore.MySql（3.0.0 预发行版以上）

根据已有数据库创建数据模型。在 NuGet 的程序包管理（Package Manager）控制台中（PowerShell）执行命令：

Scaffold-DbContext "server=数据库服务器;uid=数据库用户名;pwd=数据库密码;database=数据库名;" Pomelo.EntityFrameworkCore.MySql -OutputDir Data -Force

.Net Core CLi：

dotnet ef dbcontext scaffold "server=数据库服务器;uid=数据库用户名;pwd=数据库密码;database=数据库名;" Pomelo.EntityFrameworkCore.MySql -o Data -f

搞定。

补充：其它数据库提供程序请参考：https://docs.microsoft.com/zh-cn/ef/core/providers/

代码参数说明:

-OutputDir (-o) *** 实体文件所存放的文件目录

-ContextDir *** DbContext文件存放的目录

-Context *** DbContext文件名

-Schemas *** 需要生成实体数据的数据表所在的模式

-Tables(-t) *** 需要生成实体数据的数据表的集合

-DataAnnotations

-UseDatabaseNames 直接使用数据库中的表名和列名（某些版本不支持）

-Force (-f) 强制执行，重写已经存在的实体文件

更多高级用法请参考官方文档。

xoyozo 5 年前

7,779

从微信打开 H5 到 MAGAPP 引导过程实现

微信的 H5 页面前端引导到：
https://api.magcloud.cc/magshare/{siteId}?jump_url={jump_url}&content_url={content_url}
各参数含义见官方文档：http://doc.magcloud.net/325339
content_url 地址（一般仍为活动页面）接收参数 magshareredirect，值为 1 则跳转到自定义的引导页。
自定义引导页按 iOS 和安卓显示图文和箭头，引导用户点击右上角菜单，在浏览器中打开。
在浏览器 H5 中引导打开：
{siteId}://pagejump?jump_url={jump_url}
各参数含义见第 1 步中的文档。
这里涉及一个“若未安装则引导安装”的过程，可以选择下方合适的一种方式实现：

A 标签的 href 填入下载地址，onclick 事件 location 到 App
onclick 事件 location 到 App，再用 setTimeOut location 到下载地址
若仍无法实现预期效果，可以在弹出层中放置“未安装，前往下载”和“已安装，立即打开”两个按钮，让用户自己选择

若下载地址为应用宝，那么在 iOS 中可能会出现“打开 App 后继而自动打开 App Store”的情况，可以自建中转的 App 介绍页引导到 App Store 或应用宝。
分别实现微信和 MAGAPP 客户端的分享

xoyozo 5 年前

5,041

ASP.NET Web API 项目配置 Swagger

本文介绍 ASP.NET 的 Swagger 部署，若您使用 ASP.NET Core 应用程序，请移步 ASP.NET Core Web API Swagger 官方文档：

https://docs.microsoft.com/zh-cn/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio

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();

xoyozo 5 年前

3,365

如何减少 ASP.NET 连接 MySQL 时的 Sleep 查询（即时关闭数据库上下文）

前言：
ChatGPT 给了 3 条建议：
在应用程序中正确释放数据库连接。确保在使用完数据库连接后，将其关闭并将其返回到连接池中。您可以使用 using 语句来确保连接在使用完毕后被正确释放。
调整连接池的大小。默认情况下，连接池的最大大小为 100。如果您的应用程序需要更多的连接，则可以增加连接池的大小。您可以在连接字符串中设置 Max Pool Size 属性来调整连接池的大小。
调整连接池的超时时间。默认情况下，连接池中的连接在 30 秒钟内未使用时将被关闭。如果您的应用程序需要更长的连接时间，则可以增加连接池的超时时间。您可以在连接字符串中设置 Connection Lifetime 属性来调整连接池的超时时间。
亲测有效，尤其是第 3 条，原因是 Connection Lifetime 的默认值是 0，即没有超时限制。
—— 2023.5

一般地，我们使用 EF 连接数据库前会先初始化一个数据库上下文：

dbEntities db = new dbEntities();

虽然 ASP.NET 会在查询完毕后自动关闭该连接，但是在什么情况下回收等都是不确定的，所以会导致 MySQL 中出现很多 Sleep 的连接（执行命令 SHOW FULL PROCESSLIST 可见），占用数据库的连接数，除非主动调用 Dispose()：

db.Dispose();

官方建议的写法是使用 using 语法：

using (dbEntities db = new dbEntities())
{
}

using 会自动调用 Dispose()。这样对减少连接数是很有效的，但官方提示为了提高下一次连接的速度，并不会完全关闭所有连接。

C# 8 建议写法：

using dbEntities db = new dbEntities();

在实际项目中（该项目有 500+处数据库连接）测试结果，在不执行 Dispose() 时稳定为 140 个左右连接数，使用 using 或 Dispose() 后稳定变为 40 个左右。

如果不小心在 using 外部或 Dispose() 后再次对该上下文执行查询操作会出现异常：

无法完成该操作，因为 DbContext 已释放。

或

此 ObjectContext 实例已释放，不可再用于需要连接的操作。

所以要避免出现这种情况。这里还有一种另类的解决方法（不建议），根据上下文的特性，只要在 using 内查询一次（譬如视图中需要用到的导航属性，即外键关联的表），就可以在外部使用这个属性。

（建议）在 ASP.NET MVC 或 Web API 项目中，如果一个控制器中仅在 Action 外部定义一个 DbContext，那么，只要重写该控制器的 Dispose() 方法即可：

private dbEntities db = new dbEntities();

protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        db.Dispose();
    }
    base.Dispose(disposing);
}

上下文使用 private 修饰即可。

参考：SQL Server 连接池 (ADO.NET)

xoyozo 6 年前

5,472

微信支付接口的 return_code、result_code、trade_state

变量名	字段名	官方描述
return_code	返回状态码	SUCCESS/FAIL 此字段是通信标识，非交易标识，交易是否成功需要查看 trade_state 来判断在“统一下单”和“支付结果通知”中，该描述变成了：交易是否成功需要查看 result_code 来判断
result_code	业务结果	SUCCESS/FAIL
trade_state	交易状态	SUCCESS — 支付成功 REFUND — 转入退款 NOTPAY — 未支付 CLOSED — 已关闭 REVOKED — 已撤销（付款码支付） USERPAYING — 用户支付中（付款码支付） PAYERROR — 支付失败（其他原因，如银行返回失败）

总的来说，

return_code 是用来判断通信状态的，个人理解在“结果通知”时必为 SUCCESS；

result_code 是用来判断业务结果的，指一次调用接口或回调的动作是否如愿执行成功。如“关闭订单”时关闭成功为 SUCCESS，因参数配置错误、找不到订单号、订单状态不允许关闭等其它关闭失败的情况为 FAIL；

trade_state 是用来判断交易状态的，“交易”是指微信支付订单。

另，在“统一下单”和“支付结果通知”中，return_code 的描述变成了：交易是否成功需要查看 result_code 来判断。不知道是官方笔误，还是真的可以用来判断交易是否成功，因为在调用“统一下单”时是未支付状态，根本没有支付成功的可能。

保险起见，我们在异步收到“结果通知”时，不要相信文档去判断 result_code，应调用“查询订单”，并判断 trade_state。

xoyozo 6 年前

7,141

FileZilla 暂时没有计划支持“计划任务”和“站点对传”

用过 FlashFXP 的朋友可能会它强大的功能赞不绝口，但不免费啊，用破解版对咱们的账号安全也存在一定风险。所以平常用得最多的是免费开源的 FileZilla。

今天我把觉得 FileZilla 最应该支持的“计划任务”和“站点对传”两个功能在官方论坛进行了咨询。据 FileZilla 官方回复，暂时没有支持“计划任务”的时间表，而且由于不兼容 SFTP 的原因，服务器对服务器的直接传输也无法实现。（他可能误解了我说的“站点对传”的意思了吧）

xoyozo 6 年前

3,863

ASP.NET WEB 应用程序在发布期间预编译（彻底告别 .NET 网站首次访问速度慢的问题）

这是一篇可能解决困扰了 .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 种发布方式：

微信图片_20190715160035.png

“视为库组件（删除 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 方式发布。