Logo Logo Logo
浅色
深色
跟随系统

博客 (41)

ASP.NET 的 ActionResult
返回状态ASP.NET MVCASP.NET CoreASP.NET Web API
200 视图return View();return View();-
200 带模型的视图return View(Model);return View(Model);-
200 空内容return new EmptyResult();return Ok();return Ok();
200 文本
return Content(string);return Ok(string);
return Content(string);		return Ok(string);
return Content(string);
200 JSONreturn Json(object);

return Json(T); // 强制 JSON

return Ok(T); // 请求时可指定 Content-Type

return Json(T); // 强制 JSON

return Ok(T); // 请求时可指定 Content-Type

200 JaveScriptreturn JavaScript(string script);

200 文件return File();

return File();

return PhysicalFile();

return File();

return PhysicalFile();

201 已创建

return Created(location, content);

用于 Post 接口

301 永久跳转

return RedirectPermanent(url);

return RedirectToActionPermanent(url);

return RedirectToRoutePermanent(object);

return RedirectPermanent(url);

return RedirectToActionPermanent(url);

return RedirectToRoutePermanent(object);


302 临时跳转

return Redirect(url);

return RedirectToAction(url);

return RedirectToRoute(object);

return Redirect(url);

return RedirectToAction(url);

return RedirectToRoute(object);

return Redirect(url);

return RedirectToRoute(object);

400 错误的请求return new HttpStatusCodeResult(System.Net.HttpStatusCode.BadRequest);return BadRequest(msg);return BadRequest(msg);
401 未授权return new HttpUnauthorizedResult("描述");return Unauthorized(msg);return Unauthorized(msg);
404 找不到文件或目录return HttpNotFound(); return NotFound(msg);return NotFound(msg);
直接指定状态码

return new HttpStatusCodeResult(HttpStatusCode.*);


public enum HttpStatusCode

{

//

// 摘要:

//     等效于 HTTP 状态 100。 System.Net.HttpStatusCode.Continue 指示客户端可能继续其请求。

Continue = 100,

//

// 摘要:

//     等效于 HTTP 状态 101。 System.Net.HttpStatusCode.SwitchingProtocols 指示正在更改协议版本或协议。

SwitchingProtocols = 101,

//

// 摘要:

//     等效于 HTTP 状态 200。 System.Net.HttpStatusCode.OK 指示请求成功，且请求的信息包含在响应中。 这是最常接收的状态代码。

OK = 200,

//

// 摘要:

//     等效于 HTTP 状态 201。 System.Net.HttpStatusCode.Created 指示请求导致在响应被发送前创建新资源。

Created = 201,

//

// 摘要:

//     等效于 HTTP 状态 202。 System.Net.HttpStatusCode.Accepted 指示已接受请求做进一步处理。

Accepted = 202,

//

// 摘要:

//     等效于 HTTP 状态 203。 System.Net.HttpStatusCode.NonAuthoritativeInformation 指示返回的元信息来自缓存副本而不是原始服务器，因此可能不正确。

NonAuthoritativeInformation = 203,

//

// 摘要:

//     等效于 HTTP 状态 204。 System.Net.HttpStatusCode.NoContent 指示已成功处理请求并且响应已被设定为无内容。

NoContent = 204,

//

// 摘要:

//     等效于 HTTP 状态 205。 System.Net.HttpStatusCode.ResetContent 指示客户端应重置（而非重新加载）当前资源。

ResetContent = 205,

//

// 摘要:

//     等效于 HTTP 状态 206。 System.Net.HttpStatusCode.PartialContent 指示响应是包括字节范围的 GET 请求所请求的部分响应。

PartialContent = 206,

//

// 摘要:

//     等效于 HTTP 状态 300。 System.Net.HttpStatusCode.MultipleChoices 指示请求的信息有多种表示形式。 默认操作是将此状态视为重定向，并遵循与此响应关联的

//     Location 标头的内容。

MultipleChoices = 300,

//

// 摘要:

//     等效于 HTTP 状态 300。 System.Net.HttpStatusCode.Ambiguous 指示请求的信息有多种表示形式。 默认操作是将此状态视为重定向，并遵循与此响应关联的

//     Location 标头的内容。

Ambiguous = 300,

//

// 摘要:

//     等效于 HTTP 状态 301。 System.Net.HttpStatusCode.MovedPermanently 指示请求的信息已移到 Location

//     头中指定的 URI 处。 接收到此状态时的默认操作为遵循与响应关联的 Location 标头。

MovedPermanently = 301,

//

// 摘要:

//     等效于 HTTP 状态 301。 System.Net.HttpStatusCode.Moved 指示请求的信息已移到 Location 头中指定的 URI

//     处。 接收到此状态时的默认操作为遵循与响应关联的 Location 标头。 原始请求方法为 POST 时，重定向的请求将使用 GET 方法。

Moved = 301,

//

// 摘要:

//     等效于 HTTP 状态 302。 System.Net.HttpStatusCode.Found 指示请求的信息位于 Location 标头中指定的 URI

//     处。 接收到此状态时的默认操作为遵循与响应关联的 Location 标头。 原始请求方法为 POST 时，重定向的请求将使用 GET 方法。

Found = 302,

//

// 摘要:

//     等效于 HTTP 状态 302。 System.Net.HttpStatusCode.Redirect 指示请求的信息位于 Location 标头中指定的

//     URI 处。 接收到此状态时的默认操作为遵循与响应关联的 Location 标头。 原始请求方法为 POST 时，重定向的请求将使用 GET 方法。

Redirect = 302,

//

// 摘要:

//     等效于 HTTP 状态 303。 作为 POST 的结果，System.Net.HttpStatusCode.SeeOther 将客户端自动重定向到 Location

//     标头中指定的 URI。 用 GET 生成对 Location 标头所指定的资源的请求。

SeeOther = 303,

//

// 摘要:

//     等效于 HTTP 状态 303。 作为 POST 的结果，System.Net.HttpStatusCode.RedirectMethod 将客户端自动重定向到

//     Location 标头中指定的 URI。 用 GET 生成对 Location 标头所指定的资源的请求。

RedirectMethod = 303,

//

// 摘要:

//     等效于 HTTP 状态 304。 System.Net.HttpStatusCode.NotModified 指示客户端的缓存副本是最新的。 未传输此资源的内容。

NotModified = 304,

//

// 摘要:

//     等效于 HTTP 状态 305。 System.Net.HttpStatusCode.UseProxy 指示请求应使用位于 Location 标头中指定的

//     URI 的代理服务器。

UseProxy = 305,

//

// 摘要:

//     等效于 HTTP 状态 306。 System.Net.HttpStatusCode.Unused 是未完全指定的 HTTP/1.1 规范的建议扩展。

Unused = 306,

//

// 摘要:

//     等效于 HTTP 状态 307。 System.Net.HttpStatusCode.TemporaryRedirect 指示请求信息位于 Location

//     标头中指定的 URI 处。 接收到此状态时的默认操作为遵循与响应关联的 Location 标头。 原始请求方法为 POST 时，重定向的请求还将使用 POST

//     方法。

TemporaryRedirect = 307,

//

// 摘要:

//     等效于 HTTP 状态 307。 System.Net.HttpStatusCode.RedirectKeepVerb 指示请求信息位于 Location

//     标头中指定的 URI 处。 接收到此状态时的默认操作为遵循与响应关联的 Location 标头。 原始请求方法为 POST 时，重定向的请求还将使用 POST

//     方法。

RedirectKeepVerb = 307,

//

// 摘要:

//     等效于 HTTP 状态 400。 System.Net.HttpStatusCode.BadRequest 指示服务器未能识别请求。 如果没有其他适用的错误，或者不知道准确的错误或错误没有自己的错误代码，则发送

//     System.Net.HttpStatusCode.BadRequest。

BadRequest = 400,

//

// 摘要:

//     等效于 HTTP 状态 401。 System.Net.HttpStatusCode.Unauthorized 指示请求的资源要求身份验证。 WWW-Authenticate

//     标头包含如何执行身份验证的详细信息。

Unauthorized = 401,

//

// 摘要:

//     等效于 HTTP 状态 402。 保留 System.Net.HttpStatusCode.PaymentRequired 以供将来使用。

PaymentRequired = 402,

//

// 摘要:

//     等效于 HTTP 状态 403。 System.Net.HttpStatusCode.Forbidden 指示服务器拒绝满足请求。

Forbidden = 403,

//

// 摘要:

//     等效于 HTTP 状态 404。 System.Net.HttpStatusCode.NotFound 指示请求的资源不在服务器上。

NotFound = 404,

//

// 摘要:

//     等效于 HTTP 状态 405。 System.Net.HttpStatusCode.MethodNotAllowed 指示请求的资源上不允许请求方法（POST

//     或 GET）。

MethodNotAllowed = 405,

//

// 摘要:

//     等效于 HTTP 状态 406。 System.Net.HttpStatusCode.NotAcceptable 指示客户端已用 Accept 标头指示将不接受资源的任何可用表示形式。

NotAcceptable = 406,

//

// 摘要:

//     等效于 HTTP 状态 407。 System.Net.HttpStatusCode.ProxyAuthenticationRequired 指示请求的代理要求身份验证。

//     Proxy-authenticate 标头包含如何执行身份验证的详细信息。

ProxyAuthenticationRequired = 407,

//

// 摘要:

//     等效于 HTTP 状态 408。 System.Net.HttpStatusCode.RequestTimeout 指示客户端没有在服务器期望请求的时间内发送请求。

RequestTimeout = 408,

//

// 摘要:

//     等效于 HTTP 状态 409。 System.Net.HttpStatusCode.Conflict 指示由于服务器上的冲突而未能执行请求。

Conflict = 409,

//

// 摘要:

//     等效于 HTTP 状态 410。 System.Net.HttpStatusCode.Gone 指示请求的资源不再可用。

Gone = 410,

//

// 摘要:

//     等效于 HTTP 状态 411。 System.Net.HttpStatusCode.LengthRequired 指示缺少必需的 Content-length

//     标头。

LengthRequired = 411,

//

// 摘要:

//     等效于 HTTP 状态 412。 System.Net.HttpStatusCode.PreconditionFailed 指示为此请求设置的条件失败，且无法执行此请求。条件是用条件请求标头（如

//     If-Match、If-None-Match 或 If-Unmodified-Since）设置的。

PreconditionFailed = 412,

//

// 摘要:

//     等效于 HTTP 状态 413。 System.Net.HttpStatusCode.RequestEntityTooLarge 指示请求太大，服务器无法处理。

RequestEntityTooLarge = 413,

//

// 摘要:

//     等效于 HTTP 状态 414。 System.Net.HttpStatusCode.RequestUriTooLong 指示 URI 太长。

RequestUriTooLong = 414,

//

// 摘要:

//     等效于 HTTP 状态 415。 System.Net.HttpStatusCode.UnsupportedMediaType 指示请求是不受支持的类型。

UnsupportedMediaType = 415,

//

// 摘要:

//     等效于 HTTP 状态 416。 System.Net.HttpStatusCode.RequestedRangeNotSatisfiable 指示无法返回从资源请求的数据范围，因为范围的开头在资源的开头之前，或因为范围的结尾在资源的结尾之后。

RequestedRangeNotSatisfiable = 416,

//

// 摘要:

//     等效于 HTTP 状态 417。 System.Net.HttpStatusCode.ExpectationFailed 指示服务器未能符合 Expect

//     标头中给定的预期值。

ExpectationFailed = 417,

//

// 摘要:

//     等效于 HTTP 状态 426。 System.Net.HttpStatusCode.UpgradeRequired 指示客户端应切换为诸如 TLS/1.0

//     之类的其他协议。

UpgradeRequired = 426,

//

// 摘要:

//     等效于 HTTP 状态 500。 System.Net.HttpStatusCode.InternalServerError 指示服务器上发生了一般错误。

InternalServerError = 500,

//

// 摘要:

//     等效于 HTTP 状态 501。 System.Net.HttpStatusCode.NotImplemented 指示服务器不支持请求的函数。

NotImplemented = 501,

//

// 摘要:

//     等效于 HTTP 状态 502。 System.Net.HttpStatusCode.BadGateway 指示中间代理服务器从另一代理或原始服务器接收到错误响应。

BadGateway = 502,

//

// 摘要:

//     等效于 HTTP 状态 503。 System.Net.HttpStatusCode.ServiceUnavailable 指示服务器暂时不可用，通常是由于过多加载或维护。

ServiceUnavailable = 503,

//

// 摘要:

//     等效于 HTTP 状态 504。 System.Net.HttpStatusCode.GatewayTimeout 指示中间代理服务器在等待来自另一个代理或原始服务器的响应时已超时。

GatewayTimeout = 504,

//

// 摘要:

//     等效于 HTTP 状态 505。 System.Net.HttpStatusCode.HttpVersionNotSupported 指示服务器不支持请求的

//     HTTP 版本。

HttpVersionNotSupported = 505

}




附 ASP.NET Form 相关：

400：

Response.StatusCode = 400;
Response.Write("错误提示");
Response.End();


xoyozo 6 年前
5,927
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,855
如何升级 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 的图标。（如果没有，点开“从数据库更新模型”一下即可）

image.png

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

image.png

完成后发现，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 7 年前
8,417
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 编译 - 优化解决方案的生成性能

image.png

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


xoyozo 7 年前
5,405
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 7 年前
8,660
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());
    }
}

结果：

image.png

更多用法详见官方文档：https://docs.microsoft.com/zh-cn/aspnet/core/performance/caching/distributed?view=aspnetcore-3.0


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


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

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

xoyozo 7 年前
7,230
ASP.NET 5 / ASP.NET Core 常用功能和语法笔记

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

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


获取当前页面网址：

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


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

image.png


获取来源：

Request.GetTypedHeaders().Referer


判断 Scheme 是否为 https：

Request.IsHttps


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

image.png


获取浏览器用户代理（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 7 年前
5,314
在 CentOS 中部署 ASP.NET Core 网站

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


  1. 安装 nginx，可以使用宝塔面板。

    创建网站，保证网站静态页面能够正常访问。

    必要时配置 SSL 证书。

  2. 安装 ASP.NET Core 运行时：

    安装说明见：https://dotnet.microsoft.com/download，切换到 Linux，选择 Install .NET Core Runtime

    选择操作系统，按页面说明安装即可。

  3. 发布一个 ASP.NET Core 项目到网站目录，运行应用程序：

    dotnet 应用的程序集文件名.dll

    必须先 cd 到项目所在目录再执行，否则“Content root path”不会指向网站根目录，从而导致无法访问静态文件。

    image.png

    观察到端口为 5000（默认），该 Url 用于下一步设置反向代理。

  4. 配置 nginx 反向代理：（使用宝塔面板时建议使用面板中提供的“反向代理”功能）

    location / {
   proxy_pass http://localhost:5000;
}

  5. 查看官方详细说明：使用 Nginx 在 Linux 上托管 ASP.NET Core


xoyozo 7 年前
9,506
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,795
ASP.NET WEB 应用程序在发布期间预编译（彻底告别 .NET 网站首次访问速度慢的问题）

这是一篇可能解决困扰了 .NET 程序猿多年的文章！

首先，使用 Visual Studio 2019 创建一个 ASP.NET WEB 应用程序，直接选用了 MVC 模板。

直接发布项目，默认的设置如下图：

image.png

对于小型项目，按默认设置发布基本可满足正常运行，首次运行打开第一个页面基本在 5~6 秒（视服务器配置），其它页面的首次打开也基本在 1~2 秒完成，非首次瞬间打开。

一旦项目功能变得复杂，文件增多，会导致发布后首次运行打开第一个页面 30 秒以上，其它页面的首次打开 10 秒左右，非首次瞬间打开。

这是因为项目在发布时没有进行预编译，而是在用户访问网页时动态编译，一旦应用程序池回收，或项目文件改动，都会重新编译，再次经历缓慢的“第一次”，这是不能忍的。

于是咱们来研究一下“预编译”。

在发布页面勾选“在发布期间预编译”，这时发布会在“输出”窗口显示正在执行编译命令（编译时间会比较长）：

image.png

该选项对发布后的文件结构和内容影响不大，因此对首次执行效率的提升也不大，重要的在后面。

在“高级预编译设置”窗口中：

image.png

我们针对预编译选项和合并选项分别做测试。

不勾选“允许更新预编译站点”，会致 bin 目录中生成许多 .compiled 文件，而所有 .cshtml 文件的内容都是：

这是预编译工具生成的标记文件，不应删除!

如果是 Web From 网站，.aspx/.ashx 等文件内容同上。

尝试打开网站页面，你会发现，除了项目启动后的第一个页面仍然需要 1~2 秒（无 EF），其余每个页面的首次都是瞬间打开的（EF 的首次慢不在本文讨论范围）。这让我对预编译有一种相见恨晚的感觉！

这里偷偷地告诉你，把 Views 目录删掉也不影响网页正常打开哦~为什么不让删，咱也不敢问，咱也不敢删。

目的达到了，有一些后遗症需要解决，比如 bin 目录内杂乱无章。

选“不合并。为每个页面和控件创建单独的程序集”，结果是 bin 多出许多 App_Web_*.dll 文件。

选“将所有输出合并到单个程序集”，填写程序集名称。这时会发现“输出”窗口执行了命令：

image.png

如果程序集名称跟已有名称冲突，会发生错误：

合并程序集时出错: 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 年前
14,067
1 2 3 4 5

大家在看

Spectre.Console 常用示例
搜索引擎蜘蛛IP段
怎样查看群晖 NAS 上哪些文件占用了磁盘空间容量？
这样做会让 ASP.NET 运行得更好
在 Linux 上运行 .NET 网站，获取到 RemoteIpAddress 的结果是 ::ffff:127.0.0.1

最新发布

2026世界杯赛程
Ollama 使用集成显卡跑大模型怎么办？如何更改为用独立显卡运行？
Web 部署任务失败。未能验证服务器的证书。
QQ 浏览器在 HTTPS 环境下无法接收并存储会话 Cookie，如何解决登录态问题
赶紧修复这个潜伏了18年的 nginx 漏洞