当 MySQL 中使用 tinyint(1) 作为布尔值类型时，ASP.NET Core DBFirst 创建模型时会将其定义为 sbyte，运行时会抛出异常：
InvalidCastException: Unable to cast object of type 'System.Boolean' to type 'System.SByte'.
我们可以在数据库连接字符串中加入 TreatTinyAsBoolean=false 来实现不抛出异常，但程序中赋值和判断该字段时还是会比较麻烦。
因此我更倾向于将数据库中该字段类型改为 bit(1)。
2019.11.28 注：这回遇到 tinyint(1) 映射到了 C# 的 bool，而 bit(1) 却映射到了 ulong。具体什么原因未作排查，反正哪个最终为 bool 就选哪个吧。
本文使用 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) 强制执行，重写已经存在的实体文件
更多高级用法请参考官方文档。
本文介绍 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 方式发布。
代码一：
#if DEBUG
// Debug 模式
#else
// Release 模式
#endif作用：判断 调试模式 / 发布模式
条件：须在项目属性的生成页中勾选“定义 DEBUG 常量”
适用：记录 EF 生成的 SQL 语句、控制定时器只在生产环境执行等
注意：调试和发布时应选择正确的模式
代码二：
if(Request.IsLocal) { }作用：判断 本地 / 远程
条件：在会话中
适用：显示错误详情、记录 EF 生成的 SQL 语句
注意：不能用于定时器、Application_Start、异步操作等非会话中
代码三：
if (System.Net.IPAddress.IsLoopback(HttpContext.Connection.RemoteIpAddress)) { }说明：ASP.NET Core 中的写法，用于检测 IP 地址是否为本地回环地址（IPv4 为 127.0.0.1，IPv6 为 ::1）
若在视图中使用，HttpContext 改为 ViewContext.HttpContext 或 Context
作用/条件/适用/注意：参“代码二”
代码四：
if(HttpRuntime.AppDomainAppPath == "X:\xxx\") { }作用：判断当前网站根目录路径
条件：开发环境和生产环境的根目录路径不同
适用：判断根目录路径作相应的处理，适用于以上各种情况
注意：路径有变须要修改相应程序代码
前言：
本文适合 6.x 环境，8.x 请结合参考：如何升级 ASP.NET 项目 MySql.Data 和 Connector/NET 至 8.0.x
使用 ASP.NET Core 的同学请移步：ASP.NET Core 使用 DBFirst 模式连接 MySQL 数据库
安装
开发环境
软件安装：
MySQL for Visual Studio - 用于在 Visual Studio 中连接 MySQL 数据库
Connector/NET - ADO.NET 托管提供程序
Nuget 中搜索安装 MySql.Data 和 MySql.Data.Entity
版本选择：
MySQL for Visual Studio 最新版
Connector/NET 版本必须与 MySql.Data 和 MySql.Data.Entity 版本相同，否则会出现 MySql.Data.MySqlClient.MySqlConnection 无法强制转换的错误
生产环境
软件安装：
MySQL Server - 数据库
Connector/NET - ADO.NET 托管提供程序
版本选择：
MySQL Server 最新版
Connector/NET 应与项目中使用的 MySql.Data 和 MySql.Data.Entity 版本一致。（某些项目在确保 Web.config 的 MySql.Data 版本号与 MySql.Data 和 MySql.Data.Entity 版本一致的前提下，允许服务端的 Connector/NET 小版本略低于 MySql.Data 和 MySql.Data.Entity 版本，某些项目允许安装比 MySql.Data 和 MySql.Data.Entity 版本略高的 Connector/NET 版本，为确保不出问题，严格要求版本全部一致）
升级
MySQL for Visual Studio：直接更新至最新版
MySQL Server：直接更新至最新版
MySql.Data 和 MySql.Data.Entity：升级至两者共有的新版本，更改 Web.config 中 MySql.Data 的版本号，并更新开发环境和生产环境的 Connector/NET 至相同版本（详细步骤见下方说明）
Connector/NET：视是否有相同版本的 MySql.Data 和 MySql.Data.Entity，若有，同时升级。（详细步骤见下方说明）
关于 Connector/NET 和 MySql.Data 及 MySql.Data.Entity 版本一致的说明：
某些项目在确保 Web.config 的 MySql.Data 版本号与 MySql.Data 和 MySql.Data.Entity 版本一致的前提下，允许服务端的 Connector/NET 小版本略低于 MySql.Data 和 MySql.Data.Entity 版本；
某些项目允许安装比 MySql.Data 和 MySql.Data.Entity 版本略高的 Connector/NET 版本；
为确保不出问题，严格要求版本全部一致。
但服务器上同时运行多个项目，一旦出现问题涉及面就很广，为了尽量减少影响，列出下面的升级步骤：
升级开发环境的 Connector/NET
升级各项目的 MySql.Data 和 MySql.Data.Entity
更改 Web.config 中关于 MySql.Data 的版本号（若未自动更新，项目中搜索原版本号即可）
测试运行各项目
同时发布各项目，同时升级服务器上的 Connector/NET（升级 Connector/NET 仅需几十秒）
部分项目需要删除并重新上传 bin 目录才能生效
尽管如此，发布成功以后还是会有各种各样的问题导致无法正常打开，须要有针对性地去解决，所以升级还是要趁夜深人静的时候进行
| 发布选项 \ 项目类型 | Web 窗体网站 | Web 应用程序 （Web 窗体） | Web 应用程序 （MVC） | ASP.NET Core Web 应用程序 |
在发布期间预编译 Precompile during publishing | 若勾选，将 .cs 文件编译为 .dll | 无论是否勾选，都将 .cs 文件编译为 .dll | ||
允许更新预编译站点 Allow precompiled site to be updatable | 若不允许，则会将 .aspx 等页面也一同编译，并以内容“这是预编译工具生成的标记文件，不应删除!”代替 | |||
未进行完整的测试和分析，总结有误请指正。
可能 VS2017 目前还没有完善这个功能，只能选择发布到文件夹再通过 FTP 工具上传到服务器，期待 VS2017 更新。
参考资料：
https://stackoverflow.com/questions/43162185/trouble-publishing-net-core-project-in-vs-2017?rq=1
2017-8-15 最新版的 Visual Studio 2017 (version 15.3) 已经解决了这个问题，前往下载更新
在 NuGet 中安装
Microsoft.AspNetCore.Session和Newtonsoft.Json打开 Startup.cs，在 ConfigureServices 方法中加入（视情况配置相关属性）
services.AddSession(options => { // 设置了一个较短的时间，方便测试 options.IdleTimeout = TimeSpan.FromSeconds(10); options.CookieHttpOnly = true; });在 Configure 方法中加入
app.UseSession();添加 Extensions 文件夹并添加类 SessionExtensions.cs
using Microsoft.AspNetCore.Http; using Newtonsoft.Json; public static class SessionExtensions { public static void Set<T>(this ISession session, string key, T value) { session.SetString(key, JsonConvert.SerializeObject(value)); } public static T Get<T>(this ISession session, string key) { var value = session.GetString(key); return value == null ? default(T) : JsonConvert.DeserializeObject<T>(value); } }使用方法
HttpContext.Session.Set("abc", 123); var v1 = HttpContext.Session.Get<int>("abc"); HttpContext.Session.Remove("abc"); var v2 = HttpContext.Session.Get<int>("abc"); // v1 = 123, v2 = 0
问题：
Invalid use of NULL value
原因：
将字段从可空改为不可空时，数据库中存在该字段为空的行，因此更新列属性不成功。
解决：
将数据库中已存在行中填充该字段值，再执行迁移。
问题：
Duplicate column name 'xxx'
原因：
数据库中已存在该列，但迁移希望执行 AddColumn，可能是手动修改了数据库结构导致的。
解决：
删除数据库中该列（如果数据不重要），或通过删除迁移的方法回到数据库结构与 EF 快照一致的情况。
问题：
Cannot add or update a child row: a foreign key constraint fails (`xxx`.`xxx`, CONSTRAINT `xxx` FOREIGN KEY (`xxx`) REFERENCES `xxx` (`xxx`) ON DELETE CASCADE)
原因：
设置外键时，发现外键属性值不在导航属性所在表中。
解决：
添加外键属性和添加导航属性分两次迁移。
第一次迁移：添加外键属性（字段），MySQL 可设外键属性非空，迁移成功后更改默认值 0 为真实值（即外键对应的主表中存在的值）。
第二次迁移：添加导航属性（外键）。