在Linux生态系统,特别是CentOS服务器上部署.NET应用程序，曾是许多开发者眼中的挑战，随着.NET Core及后续版本的跨平台能力日益成熟，如今在CentOS上部署和运行.NET应用（包括传统的.exe项目）已成为一个标准且高效的操作流程，本文旨在提供一个详尽、清晰的指南，帮助您从环境准备到生产级服务配置，完整地将.NET应用部署到CentOS系统。
环境准备：安装.NET运行时
部署的首要前提是在CentOS服务器上安装.NET运行时，运行时是执行.NET应用所必需的核心组件，它与用于开发的SDK（Software Development Kit）不同，我们仅部署应用，因此安装运行时即可。
通过SSH连接到您的CentOS服务器,并确认系统版本，虽然命令适用于CentOS 7/8/Stream，但了解具体版本有助于处理潜在的兼容性问题。
cat /etc/centos-release
我们将添加Microsoft的软件包仓库,并安装所需的ASP.NET Core运行时，以.NET 7为例，执行以下命令：
# 添加Microsoft仓库 sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm # 安装ASP.NET Core运行时（包含.NET运行时） sudo yum install -y aspnetcore-runtime-7.0
安装完成后,通过以下命令验证是否成功：
dotnet --list-runtimes
如果输出中包含 Microsoft.AspNetCore.App 7.0.x，则表示环境已准备就绪。
部署方式的选择与实施
对于.NET应用的部署，主要有两种主流方式：框架依赖部署和自包含部署，选择哪种方式取决于您的具体需求和环境控制权。
框架依赖部署
这是最轻量的部署方式,您发布的应用程序不包含.NET运行时，而是依赖于服务器上预先安装的版本。
发布步骤：
在您的开发环境中，打开项目所在目录的终端，执行以下发布命令：
dotnet publish -c Release -o ./publish --no-self-contained -r linux-x64
-c Release: 指定发布配置为Release版本。-o ./publish: 指定输出目录。--no-self-contained: 明确指示进行框架依赖发布。-r linux-x64: 指定目标运行环境为64位Linux。
部署到CentOS：
将生成的publish文件夹内的所有文件（不包括其父目录）通过scp或其他方式上传到服务器的目标目录，例如/var/www/my-app。
在服务器上,进入该目录并使用dotnet命令来启动应用：
cd /var/www/my-app dotnet YourApplicationName.dll
注意： 在Linux环境下，我们直接运行的是程序集（.dll文件），而不是Windows下的.exe文件。dotnet命令会加载并执行这个dll。
自包含部署
这种方式会将.NET运行时与您的应用程序打包在一起，形成一个独立的发布单元。
发布步骤：
发布命令与FDD略有不同：
dotnet publish -c Release -o ./publish --self-contained true -r linux-x64
关键参数是 --self-contained true。
部署到CentOS：
将publish上传至服务器，由于它自带运行时，您可以直接运行其中的无扩展名可执行文件来启动应用：
cd /var/www/my-app ./YourApplicationName
| 部署特性 | 框架依赖部署 (FDD) | 自包含部署 (SCD) |
|---|---|---|
| 发布包大小 | 较小，仅包含应用代码 | 较大，包含.NET运行时 |
| 服务器依赖 | 需预先安装特定版本的.NET运行时 | 无需安装.NET运行时 |
| 应用隔离 | 多应用共享同一运行时，可能存在版本冲突 | 应用完全独立，隔离性好 |
| 更新维护 | 只需更新服务器上的运行时即可影响所有应用 | 需要重新发布并部署整个应用 |
配置为系统服务
为了让应用能在后台持续运行,并在服务器重启后自动启动，将其配置为systemd服务是最佳实践。
创建一个服务配置文件：
sudo nano /etc/systemd/system/my-app.service
在文件中填入以下内容,请根据实际情况修改路径和用户名：
[Unit] Description=My .NET Application [Service] WorkingDirectory=/var/www/my-app ExecStart=/usr/bin/dotnet /var/www/my-app/YourApplicationName.dll Restart=always # 如果是自包含部署，ExecStart应为： # ExecStart=/var/www/my-app/YourApplicationName RestartSec=10 SyslogIdentifier=my-app User=www-data Environment=ASPNETCORE_ENVIRONMENT=Production Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false [Install] WantedBy=multi-user.target
启用并启动服务：
sudo systemctl daemon-reload sudo systemctl enable my-app.service sudo systemctl start my-app.service
检查服务状态和日志：
sudo systemctl status my-app.service sudo journalctl -u my-app.service -f
至此,您的.NET应用已经以服务的形式稳定运行在CentOS服务器上了。
相关问答FAQs
问题1：为什么我直接将Windows编译的.exe文件复制到CentOS上运行时，会提示“cannot execute binary file”？
解答： 这个错误是因为.exe文件是为Windows操作系统和特定的CPU架构（如x86, x64）编译的原生可执行文件，CentOS（Linux）使用不同的可执行文件格式（ELF），并且系统调用和ABI（应用程序二进制接口）也完全不同，对于.NET应用，即使是.exe，它也依赖于特定平台的.NET运行时来将其中间语言（IL）编译为本地代码，您必须使用dotnet publish命令，并指定-r linux-x64目标运行时标识符（RID），为Linux平台生成一个兼容的可执行程序（对于FDD是.dll，对于SCD是无扩展名的二进制文件），而不是直接复制Windows版本的.exe。
问题2：自包含部署和框架依赖部署在实际生产中应该如何权衡选择？
解答： 这取决于您的运维策略和环境。
- 选择框架依赖部署（FDD） 您对服务器有完全的控制权，希望统一管理服务器上所有应用的.NET版本，从而简化安全更新和版本升级，这种方式更节省磁盘空间和内存，因为所有应用共享一个运行时实例，这是在云服务器或托管环境中最常见的做法。
- 选择自包含部署（SCD） 您的应用需要运行在无法保证或修改.NET运行时的环境中（客户的服务器、Docker容器中），或者您希望每个应用拥有完全隔离的运行时环境以避免潜在的版本冲突，它实现了“一次发布，到处运行”的便利性，但代价是更大的部署包体积，在微服务架构中，为了实现服务的完全独立和容器化，SCD也是一种非常受欢迎的选择。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复