软碟通制作 Windows 系统安装盘过程：

1. 下载微软官方提供的 iso 系统镜像文件

2. 如果 U 盘容量缩水，或根本无法正常使用 U 盘，使用老毛桃还原 U 盘空间

3. 打开 UltraISO，打开要写入 U 盘的 iso 文件

4. 在菜单上选择：启动 - 写入硬盘映像...

5. 选择硬盘驱动器，格式化，写入（注意：点击“写入”是按 FAT32 重新格式化的，若要制作 NTFS 文件系统的 U 盘，请先按 NTFS 格式化，然后在此界面上点击“便捷启动”-“便捷写入”）

6. 如果 U 盘足够大，可以在 U 盘里多放几个系统镜像，双击打开另一个 iso，将所有文件和文件夹复制到 U 盘上新建的目录中。这样下次需要安装什么系统时，只要把对应的系统的文件放到 U 盘根目录，其它系统移到二级目录中即可。当然还可以往里面存放一些常用软件。

另外最好常备一个带有 PE 系统的启动盘，在旧电脑上安装旧系统时经常会用到。

如果在分区那步无法删除或创建分区（提示动态卷什么的），在确认放弃磁盘中的文件的前提下，可以使用 Shift + F10 调出命令行，键入 diskpart，列出磁盘（list disk），选择磁盘（select disk 0），清除（clean），注意 U 盘启动盘也会在列表中，勿删！

重点提前看：

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。怎么办？

在 Windows 上安装 MySQL Server，提示需要安装 Microsoft Visual C++ 2013 Redistributable，但 MySQL Installer 安装向导中提供的 C++ 是 12.0.30501 版本：

导致无法正常安装 MySQL Server，仍然提示：

This application requires Visual Studio 2013 Redistributable. Please install the Redistributable then run this installer again.

解决办法是下载安装 Update for Visual C++ 2013 and Visual C++ Redistributable Package，即 12.0.40649.5 版本

安装成功

更新 .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

在 IIS 中编辑网站绑定时，提示“至少一个其他网站正在使用同一 HTTPS 绑定，而此绑定用另一个证书配置。确实要重用此 HTTPS 绑定并将其他网站重新指定为使用新证书吗?”，那么所有网站都必须使用同一个域名证书吗？

否。只要在绑定 https 域名的时候勾选“需要服务器名称指示”就行了。

使用证书链检测工具检测结果证书链（Certificate chain）不完整怎么办？

这个问题我在两台相同版本 CentOS 和相同版本宝塔面板的 Linux 服务器上遇到过，一台证书链完整，一台证书链不完整。

使用宝塔自带的 SSL 证书导入的方式可能出现这种情况（个例），关闭之，并手动配置 nginx 的 conf 文件；而再有一台，手动配置不生效，宝塔自带 SSL 成功，因此请自行尝试。

我也在两台相同版本的 Windows Server 2012 R2 上（IIS 8.5）遇到过，一台证书链完整，一台证书链不完整。

解决思路：在命令提示符中键入 mmc，打开：文件 - 添加/添加管理单元，选择“证书”添加，选择“计算机帐户”，确定。展开“证书”

在“个人 - 证书”中可以看到我们导入的域名证书，查看它的颁发者，确保在“中间证书颁发机构 - 证书”（或“受信任的根证书颁发机构”）中能够找到，找到后继续找该证书的颁发者，一直找到根证书。一般会有多个中间证书，形成一个完整的证书链，如果证书有缺失，那么尝试重新导入域名证书，或向供应商索要中间证书。

有任何改动后，在命令提示符中执行 iisreset 来重启 IIS（IIS 管理器中的“重新启动”可能重启得不彻底），并且找到网站 - 绑定 - 删除 https 类型的绑定并重新添加，以使证书生效。

检测证书链完整后，继续摸索过程中发现，删除某中间证书，然后在 IIS 中重新绑定，会自动生成中间证书，难道是域名证书中已经包含了中间证书和根证书等完整的证书链，还是 Windows 会自动下载安装这些证书呢？

在开发支付宝支付/微信支付时回调 Url 无法接收数据。

可能是证书链不完整，建议用工具检测：GeoCerts™ SSL Checker，并用上述方法补全。

>> 遇到新问题将不断补充本文 <<

上一篇介绍了如何创建用于 https 的 SSL 证书，本文讲述如何将创建好的 SSL 证书配置到 nginx 中。

导入证书

将 .key 文件和 .crt 文件上传到服务器，位置如：/etc/ssl/

配置 .conf

打开网站配置文件 *.conf，一般在 /usr/local/nginx/conf/vhost/

添加监听 443 端口：

listen 443 ssl;

添加 ssl 配置信息：

ssl_certificate /etc/ssl/yourdomain.com.crt;
ssl_certificate_key /etc/ssl/yourdomain.com.key;
ssl_prefer_server_ciphers on;

yourdomain.com.crt 和 yourdomain.com.key 改成真实的文件名

实现 http 自动跳转 https

配置非 443 端口请求跳转 443 端口访问：

if ($server_port !~ 443)
{
    rewrite ^(/.*)$ https://$host$1 permanent;
}

如果要求仅将 GET/HEAD 请求自动跳转（POST 请求自动跳转会丢失表单数据），那么改成：

set $redirect_https 0;
if ($server_port !~ 443)
{
    set $redirect_https 1;
}
if ($request_method ~ ^(GET|HEAD)$)
{
    set $redirect_https "${redirect_https}2";
}
if ($redirect_https = 12)
{
    rewrite ^(/.*)$ https://$host$1 permanent;
}

验证

最后来检查一下配置得对不对：https://www.geocerts.com/ssl_checker

扩展阅读

在 IIS 中部署 SSL

安装 SSL 证书遇到的一些问题

一、概述

    重定向常常和请求转发放在一起讨论（前者是两次不相关的请求，后者是一次请求服务器端转发），然而本文并不讨论两者的区别，而是HTTP 1.0规范和HTTP 1.1规范中关于重定向的区别，以及实际使用中的情况。

    重定向实际使用是一个响应码（301或302或303或307）和一个响应头location，当浏览器收到响应的时候check响应码是3xx，则会取出响应头中location对应的url（重定向中url的编码问题，请参看点击打开链接），然后将该url替换浏览器地址栏并发起另一次HTTP事务。

    关于301、302、303、307的区别，找不到好的文章，因此打算直撸HTTP 1.0规范和HTTP 1.1规范，结合一些实际的案例和tomcat实现，来说清楚这几个状态码的差异。

1. 百度https重定向

    如下图所示，原请求访问的是http://www.baidu.com，然后返回302和location=https://www.baidu.com，从http转到https。不过关于响应行中302状态码的描述存在争议，在下文中会详细讨论。

2. tomcat重定向源码

二、详细

    http 1.0规范中有2个重定向——301和302，在http 1.1规范中存在4个重定向——301、302、303和307，其中302是值得讨论讨论的。

1. http 1.0

301

    301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向，对于资源请求，原来的url和响应头中location的url而言，资源应该对应location中的url。对于post请求的重定向，还是需要用户确认之后才能重定向，并且应该以post方法发出重定向请求。

    关于post请求重定向用户确认的问题，实际上浏览器都没有实现；而且post请求的重定向应该发起post请求，这里浏览器也并不一定遵守，所以说HTTP规范的实现并未严格按照HTTP规范的语义。

    在301中资源对应的路径修改为location的url，在SEO中并未出现问题，但是在302中就出现了302劫持问题，请往下看。

302

    在http 1.0规范中，302表示临时重定向，location中的地址不应该被认为是资源路径，在后续的请求中应该继续使用原地址。

    规范：原请求是post，则不能自动进行重定向；原请求是get，可以自动重定向；

    实现：浏览器和服务器的实现并没有严格遵守HTTP中302的规范，服务器不加遵守的返回302，浏览器即便原请求是post也会自动重定向，导致规范和实现出现了二义性，由此衍生了一些问题，譬如302劫持，因此在HTTP 1.1中将302的规范细化成了303和307，希望以此来消除二义性。

    补充：302劫持——A站通过重定向到B站的资源xxoo，A站实际上什么都没做但是有一个比较友好的域名，web资源xxoo存在B站并由B站提供，但是B站的域名不那么友好，因此对搜索引擎而言，可能会保存A站的地址对应xxoo资源而不是B站，这就意味着B站出了资源版权、带宽、服务器的钱，但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站，A站什么都没做却被索搜引擎广而告之用户，B站做了一切却不被用户知道，价值被A站窃取了。

2. http 1.1

301

    和http 1.0规范中保持一致，注意资源对应的路径应该是location中返回的url，而不再是原请求地址。

302

    在HTTP 1.1中，实际上302是不再推荐使用的，只是为了兼容而作保留。规范中再次重申只有当原请求是GET or HEAD方式的时候才能自动的重定向，为了消除HTTP 1.0中302的二义性，在HTTP 1.1中引入了303和307来细化HTTP 1.0中302的语义。

303

    在HTTP 1.0的时候，302的规范是原请求是post不可以自动重定向，但是服务器和浏览器的实现是运行重定向。

    把HTTP 1.0规范中302的规范和实现拆分开，分别赋予HTTP 1.1中303和307，因此在HTTP 1.1中，303继承了HTTP 1.0中302的实现（即原请求是post，也允许自动进行重定向，结果是无论原请求是get还是post，都可以自动进行重定向），而307则继承了HTTP 1.0中302的规范（即如果原请求是post，则不允许进行自动重定向，结果是post不重定向，get可以自动重定向）。

307

    在http 1.1规范中，307为临时重定向，注意划红线的部分，如果重定向307的原请求不是get或者head方法，那么浏览器一定不能自动的进行重定向，即便location有url，也应该忽略。

    也就是307继承了302在HTTP 1.0中的规范（303继承了302在HTTP 1.0中的实现）。

3. 小结

    在HTTP 1.0规范中，302的规范并没有被服务器和浏览器遵守，即规范和实现出现了二义性，因此在HTTP 1.1中，将302的规范和实现拆分成了303和307。

三、结论

    虽然在不同版本的http规范中对重定向赋予了不同的语义，但是因为使用历史和服务器实现等原因，在实际中并不一定安全按照http规范实现，因此我个人感觉上述讨论只是一个了解，在实际写代码中302还是继续用吧···

参考：

1. 《http 1.0规范》
2. 《http 1.1规范》

3. 博客：点击打开链接

附注：

    本文如有错漏，烦请不吝指正，谢谢！

对于具体化的查询结果，不支持该方法。

This method is not supported against a materialized query result.

可能对嵌套查询的子结果集进行 Count() 等操作，可以在内部 select 外套一层 .ToList()，我在万条记录中测试不影响执行时间，但没有具体分析生成的 SQL 语句和执行跟踪。

以静态方法为例：

实际案例：在现有代码中通过async/await实现并行

早前的一篇文章

注意事项：

• 异步编程中不能使用 Session，这点跟定时器类似。

• 不要在调用无返回值的异步方法前加 await，否则会导致无限等待。