首先在项目根目录中创建目录 Areas。
在 Areas 中添加区域，以“Admin”、“Console”两个区域为例：
VS 提醒在 Startup.cs 的 Configure() 方法中添加 app.UseMvc，此与 app.UseEndpoints 冲突，我们改为在 app.UseEndpoints 中添加 MapControllerRoute（放在 default 之前）：
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "MyArea",
pattern: "{area:exists}/{controller=Home}/{action=Index}/{id?}");
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
});给区域的控制器添加属性，如：
[Area("Admin")]
public class HomeController : Controller
{
public IActionResult Index()
{
return View();
}
}
打开 appsettings.json，添加一项配置（如下方示例中的“SiteOptions”项）
* 注意，如需配置开发环境与生产环境不同的值，可单独在 appsettings.Development.json 文件中配置不同项，格式层次须一致；
C# 中习惯用强类型的方式来操作对象，那么在项目根目录添加类（类名以 SiteOptions为例），格式与 appsettings.json 中保持一致：
public class SiteOptions
{
public ERPOptions ERP { get; set; }
public WeixinOpenOptions WeixinOpen { get; set; }
public WeixinMPOptions WeixinMP { get; set; }
public SMSOptions SMS { get; set; }
public AliyunOSSOptions AliyunOSS { get; set; }
/// <summary>
/// 单个文件上传的最大大小（MB）
/// </summary>
public int MaxSizeOfSigleFile_MB { get; set; }
/// <summary>
/// 单个文件上传的最大大小（字节）
/// </summary>
public int MaxSizeOfSigleFile_B => MaxSizeOfSigleFile_MB * 1024 * 1024;
public class ERPOptions
{
public int ChannelId { get; set; }
public string AppKey { get; set; }
}
public class WeixinOpenOptions
{
public string AppId { get; set; }
public string AppSecret { get; set; }
}
public class WeixinMPOptions
{
public string AppId { get; set; }
public string AppSecret { get; set; }
}
public class SMSOptions
{
public string AppKey { get; set; }
}
public class AliyunOSSOptions
{
public string Endpoint { get; set; }
public string AccessKeyId { get; set; }
public string AccessKeySecret { get; set; }
public string BucketName { get; set; }
/// <summary>
/// 格式：//域名/
/// </summary>
public string CdnUrl { get; set; }
}
}在 Startup 中注入 IConfiguration，并在 ConfigureServices() 方法中添加服务（注意使用 GetSection() 映射到自命名的“SiteOptions”项）
在控制器中使用：
在控制器类中键入“ctor”，并按两次 Tab 键，创建构造函数
在构造函数中注入“IOptions”，并在 Action 中使用
using Microsoft.Extensions.Options;
public class TestController : Controller
{
private readonly IOptions<SiteOptions> options;
public TestController(IOptions<SiteOptions> options)
{
this.options = options;
}
public IActionResult Index()
{
return View(options.Value.ERP.ChannelId.ToString());
}
}在视图中使用：
@using Microsoft.Extensions.Options
@inject IOptions<SiteOptions> options
@options.Value.ERP.ChannelId* 本文凡使用变量 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
本文环境：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
当 MySQL 中使用 tinyint(1) 作为布尔值类型时，ASP.NET Core DBFirst 创建模型时会将其定义为 sbyte，运行时会抛出异常：
InvalidCastException: Unable to cast object of type 'System.Boolean' to type 'System.SByte'.
我们可以在数据库连接字符串中加入 TreatTinyAsBoolean=false 来实现不抛出异常，但程序中赋值和判断该字段时还是会比较麻烦。
因此我更倾向于将数据库中该字段类型改为 bit(1)。
2019.11.28 注：这回遇到 tinyint(1) 映射到了 C# 的 bool，而 bit(1) 却映射到了 ulong。具体什么原因未作排查，反正哪个最终为 bool 就选哪个吧。
本文使用 Pomelo 提供的 Pomelo.EntityFrameworkCore.MySql，如使用 MySql.Data.EntityFrameworkCore 请移步。
对比 MySql.Data.EntityFrameworkCore 与 Pomelo.EntityFrameworkCore.MySql
本文以 Visual Studio 2019、ASP.NET Core 3.0 开发环境为例。
新建 ASP.NET Core Web 应用程序。
安装 NuGet 包：
Microsoft.EntityFrameworkCore.Tools
Pomelo.EntityFrameworkCore.MySql（3.0.0 预发行版以上）
根据已有数据库创建数据模型。在 NuGet 的程序包管理（Package Manager）控制台中（PowerShell）执行命令：
Scaffold-DbContext "server=数据库服务器;uid=数据库用户名;pwd=数据库密码;database=数据库名;" Pomelo.EntityFrameworkCore.MySql -OutputDir Data -Force.Net Core CLi：
dotnet ef dbcontext scaffold "server=数据库服务器;uid=数据库用户名;pwd=数据库密码;database=数据库名;" Pomelo.EntityFrameworkCore.MySql -o Data -f搞定。
补充：其它数据库提供程序请参考：https://docs.microsoft.com/zh-cn/ef/core/providers/
代码参数说明:
-OutputDir (-o) *** 实体文件所存放的文件目录
-ContextDir *** DbContext文件存放的目录
-Context *** DbContext文件名
-Schemas *** 需要生成实体数据的数据表所在的模式
-Tables(-t) *** 需要生成实体数据的数据表的集合
-DataAnnotations
-UseDatabaseNames 直接使用数据库中的表名和列名（某些版本不支持）
-Force (-f) 强制执行，重写已经存在的实体文件
更多高级用法请参考官方文档。
本文介绍 ASP.NET 的 Swagger 部署，若您使用 ASP.NET Core 应用程序，请移步 ASP.NET Core Web API Swagger 官方文档：
https://github.com/domaindrivendev/Swashbuckle.AspNetCore
安装
NuGet 中搜索安装 Swashbuckle，作者 Richard Morris
访问
http://您的域名/swagger
配置
显示描述
以将描述文件（xml）存放到项目的 bin 目录为例：
打开项目属性，切换到“生成”选项卡
在“配置”下拉框选择“所有配置”
更改“输出路径”为：bin\
勾选“XML 文档文件”：bin\******.xml，（默认以程序集名称命名）
打开文件：App_Start/SwaggerConfig.cs
取消注释：c.IncludeXmlComments(GetXmlCommentsPath());
添加方法：
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使枚举类型按实际文本作为参数值（而非转成索引数字）
打开文件：App_Start/SwaggerConfig.cs
取消注释：c.DescribeAllEnumsAsStrings();
这是一篇可能解决困扰了 .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 种发布方式：
“视为库组件（删除 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 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
代码一：
#if DEBUG
// Debug 模式
#else
// Release 模式
#endif作用：判断 调试模式 / 发布模式
条件：须在项目属性的生成页中勾选“定义 DEBUG 常量”
适用：记录 EF 生成的 SQL 语句、控制定时器只在生产环境执行等
注意：调试和发布时应选择正确的模式
代码二：
if(Request.IsLocal) { }作用：判断 本地 / 远程
条件：在会话中
适用：显示错误详情、记录 EF 生成的 SQL 语句
注意：不能用于定时器、Application_Start、异步操作等非会话中
代码三：
if (System.Net.IPAddress.IsLoopback(HttpContext.Connection.RemoteIpAddress)) { }说明：ASP.NET Core 中的写法，用于检测 IP 地址是否为本地回环地址（IPv4 为 127.0.0.1，IPv6 为 ::1）
若在视图中使用，HttpContext 改为 ViewContext.HttpContext 或 Context
作用/条件/适用/注意：参“代码二”
代码四：
if(HttpRuntime.AppDomainAppPath == "X:\xxx\") { }作用：判断当前网站根目录路径
条件：开发环境和生产环境的根目录路径不同
适用：判断根目录路径作相应的处理，适用于以上各种情况
注意：路径有变须要修改相应程序代码
前言：
本文适合 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 版本；
为确保不出问题，严格要求版本全部一致。
但服务器上同时运行多个项目，一旦出现问题涉及面就很广，为了尽量减少影响，列出下面的升级步骤：
升级开发环境的 Connector/NET
升级各项目的 MySql.Data 和 MySql.Data.Entity
更改 Web.config 中关于 MySql.Data 的版本号（若未自动更新，项目中搜索原版本号即可）
测试运行各项目
同时发布各项目，同时升级服务器上的 Connector/NET（升级 Connector/NET 仅需几十秒）
部分项目需要删除并重新上传 bin 目录才能生效
尽管如此，发布成功以后还是会有各种各样的问题导致无法正常打开，须要有针对性地去解决，所以升级还是要趁夜深人静的时候进行