无法向会话状态服务器发出会话状态请求。请确保 ASP.NET State Service (ASP.NET 状态服务)已启动，并且客户端端口与服务器端口相同。如果服务器位于远程计算机上，请检查 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection 的值，确保服务器接受远程请求。如果服务器位于本地计算机上，并且上面提到的注册表值不存在或者设置为 0，则状态服务器连接字符串必须使用“localhost”或“127.0.0.1”作为服务器名称。
无法连接 StateService 的原因有很多种，我遇到的情况是：
VS 中使用 IISExpress 调试项目，系统没有安装 IIS，
ASP.NET 状态服务是开启状态，
没有对系统作任何修改，无缘无故无法连接。
修改注册表、配置防火墙无效（我没有用到远程连接），
执行 aspnet_regiis -i -enables 无效，
重装 .NET Framework 4.8 Developer Pack 无效，
差点就重装系统了。
最终的解决方法是：
在“启用或关闭 Windows 功能”中勾选安装：Internet Information Services -> 万维网服务 -> 应用程序开发功能 -> ASP.NET 4.8
重启系统。
场景：每天带笔记本电脑上班，公司使用固定 IP 上网，家里网络的网段又跟公司不一样。
方法 1：两个网络环境分别使用有线连接和无线连接（鉴于笔记本无线网卡不支持 5G（802.11ac），或者有其它需求必须都使用有线连接的不适用此方法）。
方法 2：修改家里路由器的局域网 IP 地址，使其网段与公司相同（虽然仅需要一次修改，但部分路由器不允许修改局域网 IP 地址）；
方法 3：使用第三方软件一键切换（有安全隐患，且可能导致电脑网络设置出现错误）；
方法 4（推荐）：设置电脑网络连接同时使用两个 IP，具体方法如下：
打开“以太网 属性”，双击“Internet 协议版本 4 (TCP/IPv4)”，配置其中一个网络环境的 IP 地址和网关（例如我在公司上网的 IP 是 192.168.1.5，网关是 192.168.1.1）
点击“高级”，在 IP 地址栏添加另一个网络的 IP（如 192.168.31.5），在“默认网关”处添加这个网络的网关（如 192.168.31.1）
这样设置后，不管到公司还是回到家，只要网线一插就能上网，不需要每天更换 IP 地址设置了。
（图中显示了两个网络名称）
如何查看 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 方式发布。
| 未接受或拒绝过时发起 | 已允许后再发起 | 已拒绝后再发起 | |
| wx.getUserInfo | 弹 | 不弹，直接获取数据 | 弹 |
| wx.getPhoneNumber | 弹 | 弹 | 弹 |
| wx.getLocation | 弹 | 不弹，直接获取数据 | 不弹，无法获取数据，必须引导 wx.getSetting |
其它 scope 会在用到时补充……
“允许后再发起，不弹”的 scope 可在“关于XXX小程序”右上角三点按钮中的“设置”来设置是否允许。
spacedesk 是一款非常强大的虚拟投影软件，可以将其它电脑、苹果设备（iPhone、iPad）、安卓手机甚至 HTML5 浏览器作为第二屏幕。本文以一台笔记本的屏幕作为另一台笔记本的扩展记录安装配置过程。
主笔记本安装 spacedesk DRIVER
扩展笔记本安装 spacedesk VIEWER
为了保证屏幕最佳的显示效果，我们希望两台笔记本最终的显示分辨率与物理分辨率一致。
我的主笔记本分辨率 1920x1080，扩展笔记本分辨率 1366x768
主笔记本
首先在扩展笔记本中打开 spacedesk VIEWER，连接主笔记本。
在主笔记本，桌面右键“显示设置”，分别针对 1 和 2 显示器设置分辨率：
当然还可以在上上图中的“重新排列显示器”中拖动来实现屏幕内容的显示位置。
扩展笔记本
打开 spacedesk VIEWER，在菜单的 Settings 中选择 Resolutions 可设置显示分辨率：
选择 Compression Quality 可设置显示质量：
压缩（Compression）如果选择 Off，那得看你的电脑能否吃得消，否则显示效果会更卡。我的配置是压缩选择 On，颜色深度选择低，快速，质量 100，帧率选择 60 FPS：
这样比默认设置的显示效果要好很多。
如果有条件用有线连接的话，尽量不要用无线连接，能减少不少延时。
【推荐】临时口令和会话口令合二为一的流程（适合随时授权）
前提：
小程序已绑定到微信开放平台。
分两种场景：
场景一：仅需要获取 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 中相应记录的该字段为空）。
【推荐】临时口令和会话口令合二为一的流程（适合随时授权）
如果你是刚入手的小米 WiFi 电力猫，那么按说明书一步一步配置即可。这里记录一下移机的重置方法。
本次移机的场景是电力猫从一台小米路由器更换到另一台小米路由器的配置，两台小米路由器 WIFI 的 SSD 不同（假设为 WIFI-A 和 WIFI-B）。
错误做法：打开米家，切换到 WIFI-B 所在的房间，点击右上角的添加新设备，根据介绍插上子猫，并按子猫的配置键 5 秒以上。连上“xiaomi-plc-xxx”，米家显示正在连接，但到达 100% 后显示连接超时。
可能的错误原因：
没有插上主猫
该电子猫已经在米家上添加过了（在 WIFI-A 所在的房间），就无法添加到其它房间了（仅猜测，未实测）
于是，同时插上主猫和子猫，并且路由器和主猫使用网线连接，什么都不设置，过一两分钟，两猫自动会变成蓝灯（表示连接成功）。这时，如果刚才那步没有重置成功的话，打开米家主界面上的“小米电力线wifi扩展器”（如果没有删除过，还在 A 房间），里面会显示网络名称为 WIFI-A，还可能没有开“WIFI漫游”。这样虽然能连接上网，但有两个 SSD，不能实现漫游。
这时，按子猫配置键 5 秒以上，并静等一分钟以上，变回蓝灯后，再打开米家，就会看到网络名称可能是 WIFI-B-Plus，这时"WIFI漫游”也能打开了，完美扩展了 WIFI。
综上实践得出：
WIFI 是由子猫负责的，所以跟 SSD 有关的配置由子猫负责；
一台设备（这里指电子猫套餐）只能添加到米家一次，但可以更改设备所在的房间。
正确的重置电力猫步骤是：
同时插上主猫和子猫
主猫连上路由器
子猫按配置键 5 秒以上，等待一分钟以上
打开米家，进入“小米电力线wifi扩展器”，打开 WIFI 漫游
以上仅在使用小米路由器情况下实测，非小米路由器未尝试。
在 Godday 上搜索域名，会引导购买一个叫“域名购买服务”的产品（英文版上是人民币 472 元，新加坡简体中文版上的新加坡元换算成人民币更贵），稍不注意就会以为是域名本身，其实是让 Godday 联系域名所有者实现交易的服务费。付款后可设置你希望购买该域名的价格范围。
发现入坑后立刻问度娘，发现好多人跟我一样被坑。
于是按 https://sg.godaddy.com/zh/contact-us 上的 400 电话打过去，客服 MM 说原则上是不退款的哦。后来又得知我没有设置过域名报价，她说可以试试提交一下退款申请。听了十几分钟的音乐后，客服提交完毕，告诉我，如果审批成功，2 天内会收到邮件，15 天内会收到退款。
等了 48 小时没有收到邮件。第 3 天晚上，直接收到退款。