本文不定时更新中……

具备 RESTful 相关知识会更有利于学习 ASP.NET Web API：RESTful API 学习笔记

ASP.NET Web API 官网：https://www.asp.net/web-api

服务 URI Pattern

HttpResponseMessage

可提供大量控制的响应消息。 例如，以下控制器操作设置的缓存控制标头。

public class ValuesController : ApiController
{
    public HttpResponseMessage Get()
    {
        HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.OK, "value");
        response.Content = new StringContent("hello", Encoding.Unicode);
        response.Headers.CacheControl = new CacheControlHeaderValue()
        {
            MaxAge = TimeSpan.FromMinutes(20)
        };
        return response;
    } 
}

IHttpActionResult

public IHttpActionResult Get (int id)
{
    Product product = _repository.Get (id);
    if (product == null)
    {
        return NotFound(); // Returns a NotFoundResult
    }
    return Ok(product);  // Returns an OkNegotiatedContentResult
}

其他的返回类型

响应状态代码为 200 （正常）。此方法的缺点是，不能直接返回错误代码，如 404。 但是，您可以触发 HttpResponseException 的错误代码。

完善 Help 页

一般都是通过元数据注释（Metadata Annotations）来实现的描述的。

显示接口和属性的描述：

打开 HelpPage 区域的 App_Start 目录下的 HelpPageConfig.cs 文件，在 Register 方法的首行取消注释行：

config.SetDocumentationProvider(new XmlDocumentationProvider(HttpContext.Current.Server.MapPath("~/App_Data/XmlDocument.xml")));

在项目右键属性“生成”页，勾选“XML 文档文件”，并填写与上述一致的路径（App_Data/XmlDocument.xml）。

给接口加上 ResponseType 显示响应描述和示例：[ResponseType(typeof(TEntity))]

在实体模型的属性上加入 RequiredAttribute 特性可提供请求或响应中的实体的属性描述，如：[Required]

推荐使用：Swashbuckle

关于格式

在 WebApiConfig.Register() 中加入以下代码以禁止以 XML 格式输出（请按需设置）：

GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear();

Json 序列化去掉 k__BackingField

GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings.ContractResolver = new Newtonsoft.Json.Serialization.DefaultContractResolver { IgnoreSerializableAttribute = true };

如果属性值为 null 则不序列化该属性

config.Formatters.JsonFormatter.SerializerSettings = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore };

前言：

本文适合 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 版本；

为确保不出问题，严格要求版本全部一致。

但服务器上同时运行多个项目，一旦出现问题涉及面就很广，为了尽量减少影响，列出下面的升级步骤：

1. 升级开发环境的 Connector/NET

2. 升级各项目的 MySql.Data 和 MySql.Data.Entity

3. 更改 Web.config 中关于 MySql.Data 的版本号（若未自动更新，项目中搜索原版本号即可）

4. 测试运行各项目

5. 同时发布各项目，同时升级服务器上的 Connector/NET（升级 Connector/NET 仅需几十秒）

6. 部分项目需要删除并重新上传 bin 目录才能生效

7. 尽管如此，发布成功以后还是会有各种各样的问题导致无法正常打开，须要有针对性地去解决，所以升级还是要趁夜深人静的时候进行

工作这几年碰到的版本检测升级的接口也算是五花八门，啥样的都有，但肯定有的功能是有个 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 做相应的判断后给出是否强制更新。
后端逻辑如下：

1. 如果 currentVersion < newVersion, 则 isUpdate = true；

• 如果 currentVersion < minVersion, 则 forceUpdate = true；

• 如果 currentVersion >= minVersion, 则 forceUpdate = false;

• 如果有特殊需求可指定某个版本必须强制更新，如 currentVersion == XXX, 则 forceUpdate = true;

2. 如果 currentVersion == newVersion，则 isUpdate = false.

结论：
返回客户端的字段仅需要 apk 下载 url : apkUrl、更新文案 : updateDescription、是否有更新 : isUpdate 、 是否强制更新 : forceUpdate 这四个字段即可。

方案二（前端处理逻辑）：
逻辑和后端处理逻辑大体上一致，只是把逻辑判断移到前台，故需要后端提供最新版本号 ：newVersion 、 最小支持版本号 : minVersion 、apk下载url : apkUrl 、更新文案 : updateDescription 这四个字段。

客户端逻辑如下：

1. 如果 currentVersion < newVersion, 则有更新信息；

• 如果 currentVersion < minVersion, 则需要强制更新；

• 如果 currentVersion >= minVersion, 则不需要强制更新;

2. 如果 currentVersion == newVersion，则没有更新信息。

总结：
细心的你可能会发现上面的可选字段 apkSize 和 md5 并没有用到，既然是可选字段也就是可用可不用，根据需要决定是否采用，这里来讲下他们的用处。

• apk 文件大小 apkSize
  这个用处可以说出于考虑用户体验，需要在升级弹框出来展示给用户将要更新的内容多大，让用户决定在非 WIFI 状态是否要更新，不能为了拉用户下载量或所谓的 UV 数直接让用户在不知道大小的情况下去直接下载（土豪用户绕路）。

• apk 的文件 MD5 值
  这个主要是出于安全考虑吧，因为文件内容固定的话对应的 md5 是一样的，我们可以通过这个 md5 值来和下载的 apk 的 md5 值进行比较去保证我们从服务器更新下载的 apk 是一个完整的未被篡改的安装包，也就是说如果我们下载的 apk 的 md5 值和服务器返回的 md5 值相等，则说明我们下载的 apk 是完整的，且没有被相关有心人处理过的 apk。

综上所述，这个版本更新的处理逻辑客户端和后端谁来做都可以，无关乎懒不懒的问题，个人感觉灵活性后端比客户端方便多了，毕竟后端可以指定 minVersion 与 newVersion 中间的任意一个版本强制更新，而客户端做起来就没有那么灵活了，个人见解，如有更好的方案，欢迎指教。

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。

以一张包含 2000 万条记录的表做实验：

CREATE TABLE `dt_read`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `time` datetime(0) NOT NULL,
  `a_id` int(11) NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
);

这张表是用于记录文章点击量的，

`id` 为主键，int(11) 自增；

`time` 为非空 datetime，表示文章打开时间，测试数据是从 2017-03-11 至 2018-04-28；

`a_id` 为非空 int(11)，表示文章 ID，在此表中不唯一，测试数据是从 1 至 260218。

体验“全表扫描”

首先来体验一下什么是全表扫描，执行下面语句：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10

> 时间: 0.012s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 7.317s

表中数据是按主键从小到大排列的，当查询条件为 `time` < '2020-1-1' 时，能很快地从表的前端找到 10 条满足条件的数据，所以不再继续判断后面的记录，立刻返回结果，耗时 0.012 秒；但当条件改为 `time` < '2000-1-1' 时，同样逐条判断，直到最后一条也没有找到，这种情况就是所谓的“全表扫描”，耗时 7 秒。

索引对 ORDER BY 的 ASC 和 DESC 的影响

我们给 `time` 建一个索引，同样执行刚才需要全表扫描的语句：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 0.012s

创建 `time` 的索引后，相当于生成了一张按 `time` 字段排列的新表，这时 MySQL 就能够很快地定位并找到符合条件的记录，避免了全表扫描。

试试按 `time` 倒序排：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10

> 时间: 0.013s

结论：索引对 ORDER BY 的顺序（ASC）和倒序（DESC）都是有效的。

索引字段的次序对 WHERE 和 ORDER BY 的影响

删除所有索引，创建一个新的索引，字段依次为 `time`, `a_id`。

分别执行以下查询：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10

> 时间: 0.013s

结论：MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。

但在 ORDER BY 中却不是这么回事了：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10

> 时间: 14.066s

原因也很好理解，对两个字段进行排序，先后次序肯定会影响结果集，因此只能以 SQL 语句指定的字段次序来 ORDER BY，这样，按索引的字段次序进行 ORDER BY 查询无疑是更快的。

索引中的字段必须依次使用

保持上例创建的索引不变，即 `time`, `a_id`。

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10

> 时间: 6.438s

上句合理利用了索引的字段，而下句跳过了 `time`，直接 WHERE 了 `a_id`，这是不受该索引支持的。

我们可以想象一下这张由索引生成的虚拟表，其实就是一张普通的平面二维表格，按索引指定的字段次序进行了排序，所以全表中仅仅是索引指定的第一个字段是按大小排列的，第二个字段是在第一个字段值相同的区域内按大小排列，后同。所以，跳过索引指定的第一个字段直接对第二个字段进行检索，是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 29.566s

WHERE 和 ORDER BY 混合

保持上例创建的索引不变，即 `time`, `a_id`。

先来执行这两句：

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 12.29s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

仅仅 WHERE 了一个 `time`，对 ORDER BY `a_id` 的效率却有质的提升，是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗？答案是否定的。

我们把时间改大，让它能马上找到符合条件的数据：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 22.34s

为什么这个语句就不走索引了呢？

其实，一个简单的 SELECT 查询语句，首先执行 WHERE，然后 ORDER BY，最后是 LIMIT。每一步都独自去找了索引，而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的，最终才是快的。

当 `time` < '2000-1-1' 时，WHERE 用到了索引，所以很快，ORDER BY 却没有用到索引，但为什么也很快呢？因为 WHERE 的结果集非常小（示例中为 0 条）。

当 `time` < '2020-1-1' 时，WHERE 也用到了索引，但其结果集非常大（示例中为所有记录），再 ORDER BY `a_id` 就非常慢了，因为我们没有创建以 `a_id` 开头的索引。

现在把索引改成只有 `time` 一个字段。

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 6.033s

因为索引里有 `

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10

> 时间: 6.033s

第二句先 WHERE `a_id`，后 ORDER BY `time` 是不能匹配所建的索引的。

索引中的字段越多越好

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

本例使用 ORDER BY 而不是 WHERE 来测试是因为，在 WHERE 的多个条件下，如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足，无法判断索引是否起作用。

SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 0.013s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 15.015s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.014s

可以看到，在索引字段依次使用的前提下，索引字段数不少于查询字段数才能避免全表扫描。

虽然索引中的字段越多越好，但必须依次使用，否则也是无效索引。

索引对 INSERT / UPDATE / DELETE 的效率影响

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000（注：存在该 id 值的记录）

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引，但从实测数据来看，索引对其效率的影响可忽略不计。

一些误区

“in 语法效率很低”?

in 语法也是应用索引的，网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。

另外：

对于字符串类型，LIKE '%abc%' 是不能应用索引的，但 LIKE 'abc%' 可以。更多关于字符串类型的索引，请查阅全文索引（FULLTEXT）。

索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。

本文系个人实践总结，欢迎批评指正！

未进行完整的测试和分析，总结有误请指正。

重点提前看：

https://xoyozo.net/Blog/Details/MySQL-on-Windows

Connector/Net 6.10.4（暂）不支持在 Visual Studio 2015/2017 添加 ADO.NET 实体数据模型时选择 MySQL Data Provider 数据源。并且，在编译项目时会出现“违反了继承安全性规则”的异常。

只能降回 Connector/Net 6.9.10，NuGet 中将 MySql.Data 和 MySql.Data.Entity 用 6.9.10 和 6.10.4 版本皆可（除非遇到下文中提到的异常）。

重新生成或重启 VS 使之生效。

另外，MySql.Data 和 MySql.Data.Entity 6.9.10 可以配合 EnityFramework 和 EntityFramework.zh-Hans 6.1.x 和 6.2.0 使用。

MySql.Data 和 MySql.Data.Entity 6.9.9 在创建/更新实体模型向导中会出现闪退，更换为 6.9.10 试试。

或重新安装 Connector/NET 和 MySQL for Visual Studio 并重启电脑试试。

仍然闪退，参此文：https://xoyozo.net/Blog/Details/mysql-for-vs-flashback。

重要提醒，如果在添加 EF 模型时报错：

您的项目引用了最新版的实体框架；但是，找不到进行数据连接所需的与此版本兼容的实体框架数据库提供程序。请退出向导，安装兼容提供程序，重新生成您的项目，然后再执行此操作。

那么在菜单中选择：生成 - 清理解决方案，然后直接添加数据模型。如果在添加前生成了项目（bin 目录下有相关 .dll 文件），那么将出现上述错误。

类型“MySql.Data.MySqlClient.MySqlProviderServices”违反了继承安全性规则。派生类型必须与基类型的安全可访问性匹配或者比基类型的安全可访问性低。

将 MySql.Data 和 MySql.Data.Entity 从 6.10.4 退回 6.9.10 版本即可。

以上问题出现在：

VS 15.4.*

VS 15.4.4

VS 15.4.5

----------------

VS 15.5 已经可以在 EF 向导中连接 MySQL 数据库（Connector/Net 6.10.4），但 MySql.Data.Entity 6.10.4 编译仍然出现“违反了继承安全性规则”。另：MySQL 官网下架了 Connector/Net 6.10.4，退回提供 6.9.10 版本。

2017-12-9 发布的 Connector/Net 6.10.5 仍然存在无法在 EF 向导中连接 MySQL 数据源的问题。

服务器上安装 Connector/Net 6.10.4 没有任何问题。

表“TableDetails”中列“IsPrimaryKey”的值为 DBNull。怎么办？

更新 .edmx 文件时若提示：

生成模型时出现意外错误。有关详细信息，请参阅输出窗口。异常消息:“StrongTypingException: 表“TableDetails”中列“IsPrimaryKey”的值为 DBNull。”。

可以通过以下方法来解决：

1，控制面板中打开“服务”（或执行命令 services.msc），重新启动“MySQL57”

2，在 MySQL 中执行：

use <<database name>>;
set global optimizer_switch='derived_merge=OFF';

如果提示“1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation”，请使用超级用户进行操作。

3，搞定，试试更新 .edmx 吧。

参考资料：https://stackoverflow.com/questions/33575109/mysql-entity-the-value-for-column-isprimarykey-in-table-tabledetails-is

1. 下载 Senparc 官方 Sample

   
   

2. 打开：\WeiXinMPSDK-master\src\Senparc.Weixin.MP.Sample\Senparc.Weixin.MP.Sample.sln

   
   

3. 工具 - NuGet 包管理器 - 管理解决方案的 NuGet 程序包 - 更新

   选择所有的包（Microsoft.Net.Http 无法更新，暂不勾选），更新

   Microsoft.Net.Http 是个老顽固，无法更新也无法卸载，原因是它的语言包 Microsoft.Net.Http.zh-Hans 无法安装。我们切换到“已安装”选项卡，搜索“Microsoft.Net.Http”，选中 Microsoft.Net.Http.zh-Hans 并卸载它，现在我们可以更新 Microsoft.Net.Http 了。

   
   

4. 【可能】运行报错：

   “/”应用程序中的服务器错误。

   ---

   配置错误

   说明: 在处理向该请求提供服务所需的配置文件时出错。请检查下面的特定错误详细信息并适当地修改配置文件。 
   
   分析器错误消息: 创建 system.web.webPages.razor/host 的配置节处理程序时出错: 未能加载文件或程序集“System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35”或它的某一个依赖项。找到的程序集清单定义与程序集引用不匹配。 (异常来自 HRESULT:0x80131040)
   
   源错误: 
   
   

   行 4:    <configSections> 行 5:      <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"> 行 6:        <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" /> 行 7:        <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" /> 行 8:      </sectionGroup>

   
   源文件: E:\WeiXinMPSDK-master\src\Senparc.Weixin.MP.Sample\Senparc.Weixin.MP.Sample\views\web.config    行: 6 
   

   
   

   展开 Senparc.Weixin.MP.Sample 引用，查看 System.Web.Razor 的属性，复制版本号。打开 \views\web.config，修改 System.Web.WebPages.Razor 的 Version（有 3 处）。

   
   

5. 对于小型开发项目来说，我习惯将所有代码放在同一个项目（Project）中来，所以做了以下处理：（盛派官方分离这些代码是为了同时供 MVC 和 WebForms 重用）

   在 Senparc.Weixin.MP.Sample 中添加文件夹 CommonService，将 Senparc.Weixin.MP.Sample.CommonService 项目中的文件夹和文件（.config 除外）拖到 CommonService 文件夹中。

   卸载 Senparc.Weixin.MP.Sample.CommonService 项目并删除引用。

   
   

6. 在解决方案的 Libraries 文件夹中，我们看到 Sample 项目了以下功能模块，这些就是 Senparc.Weixin 的源代码，如果不需要修改，可以卸载它们改为使用从 NuGet 获取，以便随时更新到最新版本：

   Senparc.WebSocket

   Senparc.Weixin

   Senparc.Weixin.MP

   Senparc.Weixin.MP.MvcExtension NuGet 中对应的包名为：Senparc.Weixin.MP.MVC

   Senparc.Weixin.Open

   Senparc.Weixin.Work

   Senparc.Weixin.WxOpen

   Senparc.Weixin.Cache.Memcached

   Senparc.Weixin.Cache.Redis
   

   卸载这些项目，并在 NuGet 中安装这些模块（搜索“Senparc.Weixin”第一页都在了，认准作者 Jeffrey Su）

   单元测试项目中的引用也按需更换，当然也可以卸载这些单元测试项目（视情况保留 Senparc.Weixin.MP.Sample.Tests） 。

   
   

7. 【可能】运行报错

   
   

   HTTP Error 500.19 - Internal Server Error

   无法访问请求的页面，因为该页的相关配置数据无效。

   配置源：

   134:     </sessionState>

   135:   <sessionState customProvider="Memcached" mode="Custom">

   136: <providers>

   
   

   可以在 Global.asax 的 RegisterWeixinCache() 中修改 Memcached 配置。

   或者打开 Web.config，找到 Memcached 所在的 sessionState 标签，注释掉，这样程序自动使用上方的 InProc（应用进程内）。

   如果开启了 ASP.NET State Service 服务，那么建议改用 StateServer，与 Custom 一样需要序列化，方便日后改用 Memcached 或 Redis。

   
   

8. 再次更新 NuGet，否则会提示无法加载 Enyim.Caching 的错误（报错行：MemcachedObjectCacheStrategy.RegisterServerList(memcachedConfig);）。

   
   

9. 接下来，进入微信公众平台，在左侧 开发 - 基本配置 中设置相关参数（填写“服务器地址(URL)”如“https://weixin.xoyozo.net/weixin/”），打开 Sample 项目中的 Web.config，配置我们的公众号参数。

   
   

10. 将项目发布到服务器上，尝试向公众号发送消息吧。

    
    

11. 单元测试

    设置单元测试中的公众号配置项：打开 Senparc.Weixin.MP.Test/CommonAPIs/CommonApiTest.cs，在 AppConfig 方法中可以看到支持两种配置方式，在 Senparc.Weixin.MP.Test/Config/test.config 配置文件中配置，或直接在 CommonApiTest.cs 文件中配置，前者格式如下，后者建议只在个人测试项目中使用。

    <Config>
      <AppId>YourAppId</AppId>
      <Secret>YourSecret</Secret>
      <MchId>YourMchId</MchId>
      <TenPayKey>YourTenPayKey</TenPayKey>
      <TenPayCertPath>YourTenPayCertPath</TenPayCertPath>
      <!-- 小程序 -->
      <WxOpenAppId>YourOpenAppId</WxOpenAppId>
      <WxOpenSecret>YourWxOpenSecret</WxOpenSecret>
    </Config>

    另外，将 _testOpenId 值改为自己的微信号在本公众号上的 openid。

    
    

12. 微信网页授权（OAuth2）

    打开 OAuth2Controller 控制器，将“Index”Action 中的盛派的网址（有 2 处）改成：

    Request.Url.Scheme + "://" + Request.Url.Authority + "/Oauth2/……

    
    

13. 未完待续……
    

可能 VS2017 目前还没有完善这个功能，只能选择发布到文件夹再通过 FTP 工具上传到服务器，期待 VS2017 更新。

参考资料：

https://stackoverflow.com/questions/43162185/trouble-publishing-net-core-project-in-vs-2017?rq=1

https://developercommunity.visualstudio.com/content/problem/24972/publish-not-working-in-vs-2017-ide.html

https://developercommunity.visualstudio.com/content/problem/34104/ftp-publish-finishs-published-successfully-without.html

2017-8-15 最新版的 Visual Studio 2017 (version 15.3) 已经解决了这个问题，前往下载更新