用过 FlashFXP 的朋友可能会它强大的功能赞不绝口，但不免费啊，用破解版对咱们的账号安全也存在一定风险。所以平常用得最多的是免费开源的 FileZilla。
今天我把觉得 FileZilla 最应该支持的“计划任务”和“站点对传”两个功能在官方论坛进行了咨询。据 FileZilla 官方回复，暂时没有支持“计划任务”的时间表，而且由于不兼容 SFTP 的原因，服务器对服务器的直接传输也无法实现。（他可能误解了我说的“站点对传”的意思了吧）
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 后重新安装才能解决。
如何查看 ASP 详细错误信息
解决办法：
打开 IIS，在相应网站的功能视图中双击“错误页”，在右侧“操作”栏中点击“编辑功能设置…”，将“错误响应”更改为“详细错误”。
在功能视图中双击“ASP”，展开“调试属性”，“将错误发送到浏览器”设为 True。记得在网站调试完成后还原此项设置。
若仍不显示，本地浏览器去掉了“显示 http 友好错误提示”选项。
这是一篇可能解决困扰了 .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 方式发布。
前提：
若需获取用户 unionid，则小程序必须已绑定到微信开放平台。
小程序调用 wx.login()，将 code 发送到开发者服务器
开发者服务器请求微信接口 code2Session，获得 session_key、openid，有机会获得 unionid（参 UnionID 机制说明）。因此无需任何用户授权即可获取 openid
访问须要已获取用户信息的页面时，可通过小程序端使用 button + getUserInfo 的方式请求用户授权
访问须要已获取手机号码的页面时，可通过小程序端使用 button + getPhoneNumber 的方式请求用户授权
code2session、getUserInfo、getPhoneNumber 等接口返回数据存入数据库 dt_weapp_user
服务端的任何接口均返回口令状态包（含自定义会话口令等信息），小程序端应保存于 storage
请求 getUserInfo 后应判断 detail.errMsg 是否为 getUserInfo:ok，请求 getPhoneNumber 后应判断 detail.errMsg 是否为 getPhoneNumber:ok
授权窗口的弹出情况参此文
口令状态包是用来传递到客户端用来标识用户唯一凭证的，包含字段：会话口令（自定义用户凭证）、会话口令有效时间（秒）、是否已获取 unionid 或昵称（视业务需求）、是否已获取手机号码、uid（可选），以及其他用来标识业务身份字段。服务端可根据会话口令从数据库中获取该用户的所有已知信息。
一般情况下，当已获取手机号码时，uid 必有值，否则，uid 必为空。因此 uid 不是必须传递到客户端的。
通过 code2Session 获得的 session_key、以及 openid、unionid、手机号码等机密信息不允许包含在口令状态包中并缓存在客户端，客户端需要用到手机号码时单独调用接口获取。
若业务不要求以手机号码作为用户唯一标识，那么口令状态包中不需要包含是否已获取手机号码，仅 uid 即可。在客户端访问须要业务用户登录的页面时，也仅判断 uid 有值即可。
流程图：
为更好地适应 2017.7.19 发布的《小程序内用户帐号登录规范调整和优化建议》，开发者服务器提供的所有业务逻辑接口的返回值中都应包含口令状态包，约定有以下相关的返回值和处理动作（返回值按个人喜好来定）：
| 口令状态 | 接口返回 | ASP.NET Web API 语句 | 处理动作 |
| access_token 空或失效 | 401 状态码 | return Unauthorized(); | login() + code2Session，获取 openid，生成 access_token |
| access_token 有效，但未获取 uniond 或用户信息 | 401 状态码，http 头 WWW-Authenticate 中标注 getUserInfo | return Unauthorized(new AuthenticationHeaderValue("getUserInfo")); | getUserInfo() |
| access_token 有效，但未获取手机号码（即未找到业务用户） | 401 状态码，http 头 WWW-Authenticate 中标注 getPhoneNumber | return Unauthorized(new AuthenticationHeaderValue("getPhoneNumber")); | getPhoneNumber() |
WWW-Authenticate 有大小写的问题，千万别入坑，参：https://xoyozo.net/Blog/Details/header-www-authenticate
返回内容是根据业务逻辑在服务端决定的，客户端在处理每个接口返回值时对返回内容作相应的处理即可。
【推荐】临时口令和会话口令合二为一的流程（适合随时授权）
前提：
小程序已绑定到微信开放平台。
分两种场景：
场景一：仅需要获取 unionid，且不需要获取头像昵称等用户信息，且已经有很大部分用户仅通过 code2Session 就能获取到 unionid（如：已关注了绑定同一微信开放平台的其它公众号，参 UnionID 机制说明）；
场景二：仅需要获取 unionid，或需要获取 unionid 及头像昵称等用户信息，或很大部分用户不能通过 code2Session 获取到 unionid。
场景一步骤：
小程序调用 wx.login()，将 code 发送到开发者服务器
开发者服务器请求微信接口 code2Session，获得 session_key、openid，有机会获得 unionid
若没有返回 unionid，尝试用 openid 从数据库中获取 unionid
如果数据库中没有找到对应的 unionid，告知小程序端使用 button + getUserInfo 的方式请求用户授权
授权允许（判断 detail.errMsg 是否为 getUserInfo:ok）则将加密数据传回开发者服务器进行解密，得到 unionid、头像、昵称等信息，保存到数据库
若授权拒绝，则无动作，用户再次点击 button 会重新弹起授权框
* 该流程仅部分用户的首次使用才要求授权。其它注意事项和流程细节见下方流程图。
场景二步骤：
小程序调用 wx.login()，将 code 发送到开发者服务器
开发者服务器请求微信接口 code2Session，获得 session_key、openid
尝试用 openid 从数据库中获取 unionid 和/或 用户信息
如果数据库中没有找到对应的 unionid 和/或 用户信息，告知小程序端使用 button + getUserInfo 的方式请求用户授权
授权允许（判断 detail.errMsg 是否为 getUserInfo:ok）则将加密数据传回开发者服务器进行解密，得到 unionid、头像、昵称等信息，保存到数据库
若授权拒绝，则无动作，用户再次点击 button 会重新弹起授权框
* 该流程仅每个用户的首次使用才要求授权。其它注意事项和流程细节见下方流程图。
上述两种场景的设计流程，只要数据库中已保存用户的 unionid（和/或 用户信息），都不再需要用户再次授权（即使在“设置”中关闭了“用户信息”授权，点击小程序右上角三点按钮，选择关于小程序，点击右上角的三点，选择设置）。
场景一流程图：
场景二流程图：
流程图中的“临时口令”仅用于关联“通过 code2Session 获得的 session_key”，并在用户授权后带回换取 session_key。原因是 session_key 是机密数据，不允许被传到小程序端。临时口令用完即删（设置表 dt__weapp_code2session 中相应记录的该字段为空）。
【推荐】临时口令和会话口令合二为一的流程（适合随时授权）
一般地，我们会设置网站中的图片文件仅允许本网站页面调用，或者开放地址栏直接打开，但不允许其它网站调用。
这就需要在 Web 服务器上判断图片的来源（Referer）。
但是，当网站页面是 https，而图片地址是 http 时，考虑到安全性，浏览器将不带 Referer，这时如果图片允许在地址栏直接打开（即 Referer 为空），就起不到防盗链的作用了。
所以图片服务器在处理防盗链时，尽量不要允许 Referer 为空时调用。这时如果要单独允许另一个网站来调用图片，应该使用一致的 protocol。
HTTP Error 502.5 - ANCM Out-Of-Process Startup 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
发现装错了东西，服务器上应该安装 dotnet-hosting-*.*.*-win.exe，而非 dotnet-runtime-*.*.*-win-x64.exe
Access to XMLHttpRequest at '********' from origin '********' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
如果仅仅是在开发环境调试，可以安装 Chrome 插件；
也可以在 PHP、ASP.NET 等后端语言中设置 header；
当然还可以在 Web 服务器上设置，如在 IIS 中：
点击“IIS 响应标头”，添加 Access-Control-Allow-Origin
总之，是在资源端设置是否允许跨域访问。
譬如使用网页播放器播放阿里云直播流时，需要在阿里云视频点播控制台-域名管理-HTTP头配置 中设置。
更多信息：
在学习和使用 ASP.NET Web API 之前，最好先对 RESTful 有所了解。它是一种软件架构风格、设计风格，而不是标准。
推荐视频教程：https://www.imooc.com/learn/811
讲师：会飞的鱼Xia
需时：2小时25分
REST API 测试工具：
在 Chrome 网上应用店中搜索：Restlet Client
或网站 https://client.restlet.com
>>> 资源路径
SCHEME :// HOST [ ":" PORT ] [ PATH [ "?" QUERY ]]
其中 PATH 中的资源名称应该使用复数名词，举例：
GET https://xoyozo.net/api/Articles/{id}
POST https://xoyozo.net/api/Articles
>>> HTTP verb（对应 CURD 操作）：
| 方法 | 功能 | ASP.NET Web API 接口返回类型（一般的） |
|---|---|---|
| GET | 取一个或多个资源 | T 或 IEnumerable<T> |
| POST | 增加一个资源 | T |
| PUT | 修改一个资源 | T |
| DELETE | 删除一个资源 | void |
| PATCH | 更新一个资源（资源的部分属性） | |
| HEAD | 获取报头 | |
| OPTIONS | 查询服务器性能或资源相关选项和需求 |
>>> 过滤信息：
如分页、搜索等
>>> 常用状态码：
| 200 | OK | 指示请求已成功 |
| 201 | Created | 资源创建成功（常见用例是一个 PUT 请求的结果） |
| 202 | Accepted | 该请求已被接收但尚未起作用。它是非承诺的，这意味着HTTP中没有办法稍后发送指示处理请求结果的异步响应。 |
| 204 | No Content | 成功 PUT（修改）或 DELETE（删除）一个资源后返回空内容（ASP.NET Web API 中将接口返回类型设置为 void 即可） |
| 400 | Bad Request | 服务器无法理解请求（如必填项未填、内容超长、分页大小超限等），幂等 |
| 401 | Unauthorized | 未授权（如用户未登录时执行了须要登录才能执行的操作），通俗地讲，是服务器告诉你，“你没有通过身份验证 - 根本没有进行身份验证或验证不正确 - 但请重新进行身份验证并再试一次。”这是暂时的，服务器要求你在获得授权后再试一次。 |
| 403 | Forbidden | 服务器理解请求但拒绝授权（是永久禁止的并且与应用程序逻辑相关联（如不正确的密码、尝试删除其它用户发表的文章）、IP 被禁止等），通俗地讲，是服务器告诉你，“我很抱歉。我知道你是谁 - 我相信你说你是谁 - 但你只是没有权限访问此资源。” |
| 404 | Not Found | 找不到请求的资源（指资源不存在，如果找到但无权访问则应返回 403） |
| 405 | Method Not Allowed | 请求方法被禁用（HTTP 动词） |
| 500 | Internal Server Error | 服务器遇到阻止它履行请求的意外情况（如数据库连接失败） |
| 503 | Service Unavailable | 服务器尚未准备好处理请求（常见原因是服务器因维护或重载而停机，这是临时的，可用于在单线程处理事务时遇到被锁定时的响应，如抽奖活动、抢楼活动，防止因并发导致逻辑错误） |
>> 错误处理：
C# 例：throw new HttpResponseException(HttpStatusCode.NotFound);
PHP 例：throw new Exception('文章不存在', 404);
>>> 返回结果：
JSON/XML
不要返回密码等机密字段
>>> 其它：
身份验证窗口（浏览器弹窗，类似 alert，非页面表单），明文传输，安全性不高，不建议使用。实现：
在 Headers 中添加 Authorization:Basic “用户名:密码”的 Base64 编码