本文介绍 ASP.NET 的 Swagger 部署，若您使用 ASP.NET Core 应用程序，请移步 ASP.NET Core Web API Swagger 官方文档：

https://docs.microsoft.com/zh-cn/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio

https://github.com/domaindrivendev/Swashbuckle.AspNetCore

安装

NuGet 中搜索安装 Swashbuckle，作者 Richard Morris

访问

http://您的域名/swagger

配置

显示描述

以将描述文件（xml）存放到项目的 bin 目录为例：

1. 打开项目属性，切换到“生成”选项卡

2. 在“配置”下拉框选择“所有配置”

3. 更改“输出路径”为：bin\

4. 勾选“XML 文档文件”：bin\******.xml，（默认以程序集名称命名）

5. 打开文件：App_Start/SwaggerConfig.cs

6. 取消注释：c.IncludeXmlComments(GetXmlCommentsPath());

7. 添加方法：

   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

使枚举类型按实际文本作为参数值（而非转成索引数字）

1. 打开文件：App_Start/SwaggerConfig.cs

2. 取消注释：c.DescribeAllEnumsAsStrings();

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。

整理成表格：

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 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
  

① 摄像头扫码：无法直接用“识别二维码”，必须把二维码发送到身边的其它设备，再使用手机摄像头完成扫码。

② 成为运营者要求绑定银行卡；成为运营者将占用“微信号绑定的帐号”数量，详见说明。若达到上限，只有法定代表人可继续成为运营者。在公众号“公众平台安全助手”中可查询绑定的帐号。

另外：

• 小程序添加/删除体验成员无须管理员授权

• 如果管理员未关注公众号“公众平台安全助手”，待测……
  

2019/2/16 补充：参见 JavaScript 中的 Truthy 和 Falsy。

使用以下代码对字符串 s 进行判断：

var s = null;
if (s) {
    console.log('true');
} else {
    console.log('false');
}

测试当 s 为不同值时的结果如下：

结论：

当 s 未定义或未赋值时，结果为 false；

当 s 为字符串类型时，长度为 0 即 false，长度大于 0 即 true；

当 s 为数字类型时，等于 0 为 false，不等于 0 为 true。

如果判断 s 的长度：

var s = null;
if (s.length > 0) {
    console.log('true');
} else {
    console.log('false');
}

那么会有以下结果：

结论：

当 s 未定义或未赋值时，异常；

当 s 为字符串类型时，长度为 0 即 false，长度大于 0 即 true；

当 s 为数字类型时，永远为 false。

这样的话，if(s.length > 0) 等同于 if(s.length)。

综上所述，判断一个字符串是否“有值且长度大于 0 ”，可以这样写：

var s = null;
if (s && s.length) {
    console.log('true');
} else {
    console.log('false');
}

相反，是否“无值或长度为 0”，可以这样写：

var s = null;
if (!s || !s.length) {
    console.log('true');
} else {
    console.log('false');
}

当然，如果要将不为 0 的数字类型也视为“有值”，只要 if(s) 或 if(!s) 即可。

这是一个数据可视化项目，基于D3.js。能够将历史数据排名转化为动态柱状图图表。

先来看看效果：

https://xoyozo.net/Demo/BarGraph

作者 Jannchie 见齐还提供了官方视频教程：

https://www.bilibili.com/video/av28087807

不过由于开源项目的不断更新，该教程的部分内容已失效，本文针对 2018-12-25 版本总结了一些常用的配置说明，仅供参考。

从 GitHub 下载源代码，在 src 目录中可以看到 4 个文件：

bargraph.html --> 运行示例页面

config.js --> 配置文件

stylesheet.css --> 样式表

visual.js --> 核心文件

作者并没有将代码封装为插件的方式，所以我们是通过修改 config.js 配置文件的方式应用到自己的项目中的。

visual.js 虽然是核心文件，但作者将部分示例中的代码也包含其中，但并不影响我们直接在自己的项目中引用。

以下是 config.js 中的主要属性：

当我们用 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="^\&amp;(.*)" />
            </conditions>
            <action type="Redirect" url="{R:1}?{C:1}" appendQueryString="false" redirectType="Temporary" />
        </rule>
    </rules>
</rewrite>

我们要把这段代码复制到开发环境源代码的 web.config 中，以免发布网站时将我们设置好的配置覆盖掉。

在学习和使用 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 操作）：

>>> 过滤信息：

如分页、搜索等

>>> 常用状态码：

>> 错误处理：

C# 例：throw new HttpResponseException(HttpStatusCode.NotFound);

PHP 例：throw new Exception('文章不存在', 404);

>>> 返回结果：

JSON/XML

不要返回密码等机密字段

>>> 其它：

身份验证窗口（浏览器弹窗，类似 alert，非页面表单），明文传输，安全性不高，不建议使用。实现：

在 Headers 中添加 Authorization:Basic “用户名:密码”的 Base64 编码

1. 首先，手机打开【设置】-【更多设置】-【关于手机】-【版本信息】，触摸“软件版本号”7次。

2. 返回【更多设置】底部出现【开发者选项】，打开后开启【USB 调试】。

3. 使用数据线连接手机和电脑（注意必须使用数据线，而非一般充电宝附带的充电线，虽然插头类型是一样的），弹出“允许 USB 调试吗？”对话框，选择“确定”。

4. 电脑上安装 vivo 手机助手，就可以管理手机了。手机端可以安装手机助手。

5. 如果需要连接 HBuilderX 进行安卓应用调试，需要从手机顶部下划，将“USB已连接”中的“管理文件”更改为“传输照片”。并使用 vivo 手机助手手动安装调试基座（控制台中会提示）。

命令格式：CertUtil -hashfile <文件名> <hash类型>

例：CertUtil -hashfile abc.iso SHA1