这是一篇可能解决困扰了 .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 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
前提：
若需获取用户 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 中相应记录的该字段为空）。
【推荐】临时口令和会话口令合二为一的流程（适合随时授权）
Input string is not a valid interger. Path 'batteryLevel', line 1, position 447.
使用 uni-app 开发小程序的时候，获取系统信息（getSystemInfoSync()）在 iPhone X 上报错，原因是电池电量值无法转换为 int 型。出现的情况是偶发性的，但一旦出现，一段时间内会一直出现（可能等电量值更新了才会正常吧）。不知道是 uni-app 的 bug 还是微信小程序的 bug。问了度娘和必应国际，暂时没有找到答案。
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
常用获取英文的方法是查看英文版 App。
微信：WeChat
小程序：Mini Programs
公众号：Official Accounts
订阅号：Subscriptions
朋友圈：Moments
已登录的：Logged
服务通知：Service Messages
置顶：Sticky on Top / Remove from Top
发送给朋友：Share to Friends
微信号：WeChat ID
钱包：Wallet
余额：Balance
资金/零钱/基金：Funds
金额：Amount
明细：Details
账单：Transactions
资产：Assets
收入/收益：Income
财富：Fortune
登录：Log In / Login
退出登录：Log Out / Logout
注册苹果开发者账号和发布 App 会填写一些联系邮箱，一旦账号或应用违规，苹果方也只会以解决方案中心或邮件的形式通知开发者，一旦超过时限，可能会采取一些强制措施，影响到我们的 App 正常上架运营，本文罗列了一些相关的电子邮箱，如有不全请指正。
在注册 Apple ID （https://appleid.apple.com/account/manage）时会填写 3 个邮箱，一个用于登录用户名，一个作为常规联系，第 3 个是用于救援（估计是常规联系邮箱失效时才会用到）。
在 App Store Connect （https://appstoreconnect.apple.com/）中发布新版本 App 时会填写两个邮箱，一个是 App 的联系邮箱，一个是审核联系邮箱。
当我们在联系审核团队（https://developer.apple.com/contact/app-store/）时，可能会填写一个邮箱，用于针对当前问题进行反馈。
苹果的“联系我们”（https://developer.apple.com/contact/）
其它一些主动提交的信息，用于反馈，如：投诉侵犯知识产权（https://www.apple.com/legal/internet-services/itunes/appstorenotices/#?lang=zh）
本文基于初期只开放微信小程序，后期向 iOS/Android/H5 等多终端开放的场景设计，且并不要求“登录即必须绑定手机号码”。如初期即同时多终端推出请参考此文。
项目初期，微信小程序以 openid 作为用户的唯一标识，因此在其它平台也需要用微信来授权登录。但同一微信用户在小程序和 App 上使用微信授权登录后的 openid 并不相同，必须同时绑定到微信开放平台，通过 unionid 关联用户，作为用户的唯一标识。
当我们用 ASP.NET Web API 作服务端接口时，如果客户端以 GET 方式请求的 URL 中，由于拼接错误导致“？”和“&”并列出现，会发生 400 Bad Request，那么需要在 IIS 中使用 URL 重写模块来纠正。
请求 URL 如：
http://www.abc.com/api/obj?&foo=bar
需要重写为：
http://www.abc.com/api/obj?foo=bar
打开 IIS 管理器中对应网站的 URL 重写，
添加空白规则。
匹配的 URL 不包含域名，如上述 URL 则匹配的范围是：
api/obj
不包含我们要查找的字符串 ?&，所以此处模式只能匹配所有：
.*
又因为重定向路径中需要包含这部分，所以用括号包裹，即：
(.*)
继续添加条件匹配：
条件输入：{QUERY_STRING}，表示匹配查询字符串，
匹配的部分是“?”后面的字符串：
&foo=bar
那么可以填写模式：
^\&.*
因为 & 后面的部分仍然需要使用，所以用括号包裹：
^\&(.*)
“操作”中选择类型“重定向”，URL 填写：
{R:1}?{C:1}
其中 {R:1} 指代 api/obj，{C:1} 指代 foo=bar
取消“附加查询字符串”前面的勾
重定向类型在测试时可以选择 302 或 307，没问题后选择 301。
完成。
最终我们可以在网站的配置文件 web.config 中看到：
<rewrite>
<rules>
<rule name="uni-app-h5-replace-q" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{QUERY_STRING}" pattern="^\&(.*)" />
</conditions>
<action type="Redirect" url="{R:1}?{C:1}" appendQueryString="false" redirectType="Temporary" />
</rule>
</rules>
</rewrite>我们要把这段代码复制到开发环境源代码的 web.config 中，以免发布网站时将我们设置好的配置覆盖掉。
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头配置 中设置。
更多信息：