The specified version of Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found.

异常提示：

HTTP Error 500.31 - ANCM Failed to Find Native Dependencies

Common solutions to this issue:

The specified version of Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found.

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=2028526

解决方法：

安装对应版本（或最新版本）的 ASP.NET Core Runtime，前往下载：https://dotnet.microsoft.com/download

xoyozo 6 年前

14,147

如何升级 ASP.NET 项目 MySql.Data 和 Connector/NET 至 8.0.x

本教程教你如何升级 ASP.NET 项目中的 MySql.Data 和服务器安装的 Connector/NET 版本至 8.0.18。

使用 MySQL Application Configuration 升级 MySql.Data

双击打开 .edmx 文件后，解决方案资源管理器上会有 MySQL Application Configuration 的图标。（如果没有，点开“从数据库更新模型”一下即可）

勾选“Use MySQL with Entity Framework”，安装完成。

完成后发现，Nuget 中会自动安装或升级下面两个组件：

MySql.Data 8.0.18

MySql.Data.EntityFramework 8.0.18

并且在 Web.config 中会自动添加以下节点：

<system.data>
  <DbProviderFactories>
    <remove invariant="MySql.Data.MySqlClient" />
    <add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient" description=".Net Framework Data Provider for MySQL" type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=8.0.18, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
  </DbProviderFactories>
</system.data>

这段代码使 MySql.Data 8.0.18 的项目能够兼容运行在 Connector/NET 6.10.x 环境中。方便我们挨个升级服务器上的项目。

8.0.18 已经不再需要 MySql.Data.Entity 组件了，可以从 Nuget 中手动卸载。

xoyozo 6 年前

7,270

Microsoft.Net.Compilers is only supported on MSBuild v16.3 and above

Microsoft.Net.Compilers is only supported on MSBuild v16.3 and above

解决办法：菜单 - 生成 - ASP.NET 编译 - 优化解决方案的生成性能

如果没有该项，在解决方案资源管理器中选中解决方案再试。

xoyozo 6 年前

5,188

ASP.NET Core 3.0 缓存（Cache）之 MySQL 缓存

ASP.NET Core 缓存 Caching 提供了包括但不限于以下几种存储方式：

内存缓存：https://xoyozo.net/Blog/Details/aspnetcore-memory-cache

SQL Server 缓存：https://xoyozo.net/Blog/Details/aspnetcore-sql-cache

Redis 缓存：https://xoyozo.net/Blog/Details/aspnetcore-redis-cache

MySQL 缓存：https://xoyozo.net/Blog/Details/aspnetcore-mysql-cache

Nuget 安装：Pomelo.Extensions.Caching.MySql

Nuget 安装：Pomelo.Extensions.Caching.MySqlConfig.Tools（用于在 MySql 数据库中创建表和索引以进行分布式缓存的命令行工具(dotnet-mysql-cache)）

2019.11 MySqlConfig.Tools 最新版本（2.0.2）不支持 .NetCore 3.0，暂时可手动创建表和索引。

2021.11 MySqlConfig.Tools 最新版（2.1.0）不支持 .Net 6.0。

未完待续，后续步骤类似于：https://xoyozo.net/Blog/Details/aspnetcore-sql-cache

services.AddDistributedMySqlCache()

xoyozo 6 年前

8,151

ASP.NET Core 3.0 缓存（Cache）之 Redis 缓存

ASP.NET Core 缓存 Caching 提供了包括但不限于以下几种存储方式：

内存缓存：https://xoyozo.net/Blog/Details/aspnetcore-memory-cache

SQL Server 缓存：https://xoyozo.net/Blog/Details/aspnetcore-sql-cache

Redis 缓存：https://xoyozo.net/Blog/Details/aspnetcore-redis-cache

MySQL 缓存：https://xoyozo.net/Blog/Details/aspnetcore-mysql-cache

Nuget 安装：Microsoft.Extensions.Caching.StackExchangeRedis

在 Startup.cs 文件的方法 ConfigureServices() 中添加：

services.AddStackExchangeRedisCache(options =>
{
    // 连接字符串
    options.Configuration = "192.168.111.134,password=aW1HAyupRKmiZn3Q";
    // 键名前缀
    options.InstanceName = "xoyozo_";
});

在控制器中注入 IDistributedCache：

public class TestController : Controller
{
    private readonly IDistributedCache cache;

    public TestController(IDistributedCache cache)
    {
        this.cache = cache;
    }

    public IActionResult Index()
    {
        string k = "count";
        int v = Convert.ToInt32(cache.GetString(k));
        v++;
        cache.SetString(k, v.ToString());
        return Content(v.ToString());
    }
}

结果：

注：.NET 6 已不支持 Redis on Windows 3.0。

经过以上配置，Session 也会保存到 Redis 中，键名是前缀_Guid 格式。

关于 Session，参此文：https://xoyozo.net/Blog/Details/aspnetcore-session-redis

xoyozo 6 年前

6,771

ASP.NET 5 / ASP.NET Core 常用功能和语法笔记

* 本文凡使用变量 httpContextAccessor 或 _httpContextAccessor 的地方都需要需要注入 Microsoft.AspNetCore.Http.IHttpContextAccessor

* 在视图（view）中应以 ViewContext 类引出

获取当前页面网址：

using Microsoft.AspNetCore.Http.Extensions;
string url = Request.GetDisplayUrl();

获取当前访问的域名和端口：

获取来源：

Request.GetTypedHeaders().Referer

判断 Scheme 是否为 https：

Request.IsHttps

获取客户端IP和端口、服务器IP和端口：

获取浏览器用户代理（UserAgent）：

httpContextAccessor.HttpContext.Request.Headers[HeaderNames.UserAgent];

获取当前请求的唯一标识：

httpContextAccessor.HttpContext.TraceIdentifier

返回结果：80000564-0002-f700-b63f-84710c7967bb

用途：可作为生成随机数的种子。

获取客户端IP地址：

httpContextAccessor.HttpContext.Connection.RemoteIpAddress

获取当前项目根目录磁盘路径：

AppContext.BaseDirectory // 以“\”结尾

注意：此路径到项目根目录，而非网站根目录，网站根目录请自行追加，默认为 wwwroot\

编码/解码：（参数和返回值均为 string?）

using System.Net;
WebUtility.HtmlEncode(myString)
WebUtility.HtmlDecode(myString)
WebUtility.UrlEncode(myString)
WebUtility.UrlDecode(myString)

更多：https://xoyozo.net/Blog/Index/Core

xoyozo 6 年前

4,806

在 CentOS 中部署 ASP.NET Core 网站

本文环境：CentOS 7、nginx 1.16、ASP.NET Core 3.0

安装 nginx，可以使用宝塔面板。
创建网站，保证网站静态页面能够正常访问。
必要时配置 SSL 证书。
安装 ASP.NET Core 运行时：
安装说明见：https://dotnet.microsoft.com/download，切换到 Linux，选择 Install .NET Core Runtime
选择操作系统，按页面说明安装即可。
发布一个 ASP.NET Core 项目到网站目录，运行应用程序：
```
dotnet 应用的程序集文件名.dll
```
必须先 cd 到项目所在目录再执行，否则“Content root path”不会指向网站根目录，从而导致无法访问静态文件。
观察到端口为 5000（默认），该 Url 用于下一步设置反向代理。
配置 nginx 反向代理：（使用宝塔面板时建议使用面板中提供的“反向代理”功能）
```
location / {
   proxy_pass http://localhost:5000;
}
```
查看官方详细说明：使用 Nginx 在 Linux 上托管 ASP.NET Core

xoyozo 6 年前

8,225

MySQL for Visual Studio 2019

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 后重新安装才能解决。

xoyozo 7 年前

8,343

ASP.NET WEB 应用程序在发布期间预编译（彻底告别 .NET 网站首次访问速度慢的问题）

这是一篇可能解决困扰了 .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 种发布方式：

微信图片_20190715160035.png

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

xoyozo 7 年前

12,963

RESTful API 学习笔记

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

方法	功能	ASP.NET Web API 接口返回类型（一般的）
GET	取一个或多个资源	T 或 IEnumerable<T>
POST	增加一个资源	T
PUT	修改一个资源	T
DELETE	删除一个资源	void
PATCH	更新一个资源（资源的部分属性）
HEAD	获取报头
OPTIONS	查询服务器性能或资源相关选项和需求

>>> 过滤信息：

如分页、搜索等

>>> 常用状态码：

200	OK	指示请求已成功
201	Created	资源创建成功（常见用例是一个 PUT 请求的结果）
202	Accepted	该请求已被接收但尚未起作用。它是非承诺的，这意味着HTTP中没有办法稍后发送指示处理请求结果的异步响应。
204	No Content	成功 PUT（修改）或 DELETE（删除）一个资源后返回空内容（ASP.NET Web API 中将接口返回类型设置为 void 即可）
400	Bad Request	服务器无法理解请求（如必填项未填、内容超长、分页大小超限等），幂等
401	Unauthorized	未授权（如用户未登录时执行了须要登录才能执行的操作），通俗地讲，是服务器告诉你，“你没有通过身份验证 - 根本没有进行身份验证或验证不正确 - 但请重新进行身份验证并再试一次。”这是暂时的，服务器要求你在获得授权后再试一次。
403	Forbidden	服务器理解请求但拒绝授权（是永久禁止的并且与应用程序逻辑相关联（如不正确的密码、尝试删除其它用户发表的文章）、IP 被禁止等），通俗地讲，是服务器告诉你，“我很抱歉。我知道你是谁 - 我相信你说你是谁 - 但你只是没有权限访问此资源。”
404	Not Found	找不到请求的资源（指资源不存在，如果找到但无权访问则应返回 403）
405	Method Not Allowed	请求方法被禁用（HTTP 动词）
500	Internal Server Error	服务器遇到阻止它履行请求的意外情况（如数据库连接失败）
503	Service Unavailable	服务器尚未准备好处理请求（常见原因是服务器因维护或重载而停机，这是临时的，可用于在单线程处理事务时遇到被锁定时的响应，如抽奖活动、抢楼活动，防止因并发导致逻辑错误）

>> 错误处理：

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

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

>>> 返回结果：

JSON/XML

不要返回密码等机密字段

>>> 其它：

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

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

xoyozo 7 年前

5,197

1 2 3 4

HTTP Error 500.31 - ANCM Failed to Find Native Dependencies

Common solutions to this issue:

Troubleshooting steps:

For more information visit: https://go.microsoft.com/fwlink/?LinkID=2028526

大家在看

最新发布

查询 / 检测

编程

前端

行业

本站 API

博客 (40)

HTTP Error 500.31 - ANCM Failed to Find Native Dependencies

Common solutions to this issue:

Troubleshooting steps:

For more information visit: https://go.microsoft.com/fwlink/?LinkID=2028526

大家在看

最新发布