安装最新的：MySQL for Visual Studio
安装版本一致的：MySQL Connector Net、MySql.Data 和 MySql.Data.Entity
若仍闪退，在 MySQL Application Configuration 中勾选 Entity Framework 的 Use MySQL with Entity Framework
或直接升级 MySql.Data 到 8.x
在编程或生成时，我们可能会遇到如下错误：
推断出元组元素名称“category”。请使用语言版本 7.1 或更高版本按推断名称访问元素。
那么打开项目属性，切换到“生成”选项卡，“配置”选择“所有配置”。
页面往下拉，打开“高级”窗口，默认是“C# 最新主要版本(默认)”，我们选择“C# 最新次要版本(最新)”，确定。
Visual Studio 2019 已于本月早些时候正式发布，但 MySQL for Visual Studio 却迟迟未更新，目前的 1.2.8 版本只支持到 VS2017。表现在 VS2019 上会发生：
在“服务器资源管理器”中添加连接时，或在新建“ADO.NET 实体数据模型”时，无法看到数据源“MySQL Database (MySQL Data Provider)”
在实体数据模型设计器（Entity Data Model Designer）中执行“从数据库更新数据模型”时出现错误：尝试从数据库进行更新时，遇到类型为“System.ArgumentException”的异常。异常消息为:“无法将运行时连接字符串转换为设计时等效项。没有为提供程序“MySql.Data.MySqlClient”安装为设计目的(DDEX 提供程序)启用 Visual Studio 以便与数据库进行通信所需的库。
幸运的是 VS2019 可以与低版本 VS 共存，使用 ASP.NET 连接 MySQL 的开发者们要再等一等才能用上 VS2019 了。
这几天 MySQL 不断有产品更新，相信 MySQL for Visual Studio 2019 也会在不久的将来面世，本站将第一时间更新下载地址。
2019.8.30 Jose Ramirez（来自 MySQL 的 Windows 团队）：MySQL for Visual Studio 的当前版本不支持 Visual Studio 2019。正在努力提供支持，但根据公司政策，我无法披露日期或对何时可用提供任何承诺。查看
2019.9.26 MySQL for Visual Studio 迟迟未更新，但是 VS2019 更新到最新版本（v16.3）已经一切正常了。
MySQL for Visual Studio 的 Repair 功能是鸡肋，有问题的话，Remove 后重新安装才能解决。
这是一篇可能解决困扰了 .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 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
本文作为 多平台用户登录模块设计 的扩展设计，即以手机号作为用户的唯一凭证。
官方文档的小程序登录时序：
https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/login.html
（图片摘自 2018.10.30）
session_key 是密钥，仅保存于开发者服务器，用于将小程序通过前端接口获取到的数据解密来验证其真实性。详见 https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/signature.html
小程序与服务器是通过自定义登录态来识别用户身份的，以下简称口令（token）。
由于微信未告知 session_key 的有效期，那么为保证小程序发起业务请求成功，token 须要永久有效，但这会带来安全隐患。
如果设置 token 的有效期（如 7200 秒），那么小程序发起业务请求后，服务器必须把 token 的验证结果告知小程序，若失效则重新登录。
微信授权登录（含绑定手机号码）流程图
子流程：授权登录
子流程：绑定手机号
为保证数据安全，针对每个须要授权登录的业务请求，服务器都都会检验 token 的有效性。如果小程序同时发起多个业务请求，并几乎同时收到 token 过期，那么会同时发起多个重新登录流程，服务器多次 code2Session，重新生成多个 token 返回到小程序，那么小程序最终保存的 token 可能不是服务器上认为的最新的一个 token。这样，如果程序设计为获取到 token 继而重新发起业务请求，可能会进入死循环。解决的方法是在同时发起多个业务请求之前先向服务器验证一次 token 的有效性，再发起多个业务请求时就不会出现都过期的情况了。
一般情况下升级 macOS 操作系统只需要在“关于本机”中检查软件更新即可安装，如果你的老旧 Mac 电脑不支持最新版本的 macOS，那么就会提示：我们无法完成您的购物操作，此版本的 macOS 不能安装在这台电脑上
这就需要我们打开相应版本的页面来更新你想要安装的 macOS 版本。
以下是各版本如何升级的说明：
前言：
本文适合 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 目录才能生效
尽管如此，发布成功以后还是会有各种各样的问题导致无法正常打开，须要有针对性地去解决，所以升级还是要趁夜深人静的时候进行
工作这几年碰到的版本检测升级的接口也算是五花八门，啥样的都有，但肯定有的功能是有个 apk 的下载链接，能间接或直接提示你是强制还是非强制更新：
间接是指提供你后台最新版本号，让你自己与本地版本号通过比较得出是否升级；
直接就是后台接口直接返回个 Boolean 类型告诉你是强制或者非强制更新。
个人认为一个好的版本检测接口需要设计的更灵活更清晰用起来更方便，下面就我理解的接口设计如下（如思路有误，欢迎指正）：
总字段如下(并不是所有字段都要返回给客户端)：
1.最新版本号 ：newVersion
2.最小支持版本号 : minVersion
3.apk 下载 url : apkUrl
4.更新文案 : updateDescription
5.是否有更新 : isUpdate
6.是否强制更新 : forceUpdate 可选字段：
7.apk 文件大小：apkSize
8.apk 的文件 MD5 值：md5方案一(后端处理逻辑)：
在客户端请求参数中添加当前版本号 currentVersion 传输给后台，由后台根据客户端传过来的当前版本号 currentVersion 做相应的判断后给出是否强制更新。
后端逻辑如下：
如果 currentVersion < newVersion, 则 isUpdate = true；
如果 currentVersion < minVersion, 则 forceUpdate = true；
如果 currentVersion >= minVersion, 则 forceUpdate = false;
如果有特殊需求可指定某个版本必须强制更新，如 currentVersion == XXX, 则 forceUpdate = true;
如果 currentVersion == newVersion，则 isUpdate = false.
结论：
返回客户端的字段仅需要 apk 下载 url : apkUrl、更新文案 : updateDescription、是否有更新 : isUpdate 、 是否强制更新 : forceUpdate 这四个字段即可。
方案二（前端处理逻辑）：
逻辑和后端处理逻辑大体上一致，只是把逻辑判断移到前台，故需要后端提供最新版本号 ：newVersion 、 最小支持版本号 : minVersion 、apk下载url : apkUrl 、更新文案 : updateDescription 这四个字段。
客户端逻辑如下：
如果 currentVersion < newVersion, 则有更新信息；
如果 currentVersion < minVersion, 则需要强制更新；
如果 currentVersion >= minVersion, 则不需要强制更新;
如果 currentVersion == newVersion，则没有更新信息。
总结：
细心的你可能会发现上面的可选字段 apkSize 和 md5 并没有用到，既然是可选字段也就是可用可不用，根据需要决定是否采用，这里来讲下他们的用处。
apk 文件大小 apkSize
这个用处可以说出于考虑用户体验，需要在升级弹框出来展示给用户将要更新的内容多大，让用户决定在非 WIFI 状态是否要更新，不能为了拉用户下载量或所谓的 UV 数直接让用户在不知道大小的情况下去直接下载（土豪用户绕路）。apk 的文件 MD5 值
这个主要是出于安全考虑吧，因为文件内容固定的话对应的 md5 是一样的，我们可以通过这个 md5 值来和下载的 apk 的 md5 值进行比较去保证我们从服务器更新下载的 apk 是一个完整的未被篡改的安装包，也就是说如果我们下载的 apk 的 md5 值和服务器返回的 md5 值相等，则说明我们下载的 apk 是完整的，且没有被相关有心人处理过的 apk。
综上所述，这个版本更新的处理逻辑客户端和后端谁来做都可以，无关乎懒不懒的问题，个人感觉灵活性后端比客户端方便多了，毕竟后端可以指定 minVersion 与 newVersion 中间的任意一个版本强制更新，而客户端做起来就没有那么灵活了，个人见解，如有更好的方案，欢迎指教。
如果 .NET Core 项目发布到服务器上报以下错误：
HTTP Error 502.5 - Process Failure
Common causes of this issue:
The application process failed to start
The application process started but then stopped
The application process started but failed to listen on the configured port
Troubleshooting steps:
Check the system event log for error messages
Enable logging the application process' stdout messages
Attach a debugger to the application process and inspect
For more information visit: https://go.microsoft.com/fwlink/?LinkID=808681
在服务器上安装最新的 .NET Core Runtime 即可（Windows Server 选择 Hosting Bundle Installer）。