Linux仅装.NET Core 3.1运行时无SDK，应用作systemctl启动报需SDK问题

• 你用--self-contained false参数发布的框架依赖型应用，运行阶段完全不需要安装.NET Core SDK。SDK的作用仅限开发场景：编译代码、还原项目依赖、执行发布/构建/脚手架类操作，生产环境只要安装了和目标框架版本匹配的运行时，就可以正常启动应用。你服务器上安装的ASP.NET Core 3.1.10运行时，完全满足netcoreapp3.1应用的运行要求。
• 你碰到的“找不到已安装SDK”报错，根本不是运行应用需要SDK，是dotnet命令的兜底提示逻辑在误导人：它没法正确识别到你要运行的目标程序集，或是意外触发了SDK专属的版本检查逻辑，才抛出了这个提示，本质是启动配置的问题，和应用本身的运行依赖没关系。

按出现概率从高到低排查，90%以上的同类问题都是前两步的配置错误：

1. 检查systemd服务的路径与权限配置（最高发诱因） #

dotnet的兜底逻辑非常容易踩坑：只要它接收到的参数没法定位到可运行的dll文件，不管你本来是要跑应用还是别的操作，它都会默认你要执行需要SDK的命令，此时如果服务器没装SDK，就会弹出找不到SDK的提示。

• 检查服务文件里ExecStart的写法，必须用全路径指向dotnet可执行文件和目标dll，禁止用相对路径，正确写法参考：
  ExecStart=/usr/bin/dotnet /opt/app/publish/Web.dll
• 必须配置WorkingDirectory参数，值为Web.dll所在的发布目录绝对路径。systemd启动服务时的默认工作目录是/或是服务运行用户的家目录，如果不配工作目录，哪怕你写了正确的dll绝对路径，很多应用读取配置文件、静态资源也会出问题；如果用了相对路径写dll位置，更是会因为找不到文件直接触发SDK报错。
• 确认服务配置的运行账户对整个发布目录有可读权限：如果服务用户（如www-data）没有Web.dll的读取权限，dotnet打不开目标文件，同样会触发上述兜底报错。

2. 排查发布目录中是否混入SDK专属文件 #

开发环境下的global.json文件，会强制dotnet进程先校验指定版本的SDK是否安装，这个文件仅用于开发阶段约束SDK版本，运行现有应用完全不需要。

• 遍历发布目录，看是否存在global.json文件，如果存在直接删除即可。如果dotnet在启动时读到了这个文件，哪怕你只是要跑已经编译好的dll，它也会先执行SDK版本检查，没有匹配到对应SDK就会抛出缺失提示。这也是很多人碰到的“手动在没这个文件的目录下跑就正常，切到有这个文件的目录跑就报SDK错”的核心原因。

3. 校验systemd的环境变量配置 #

手动在终端启动时，会自动加载当前登录用户的shell环境变量，包括dotnet相关的路径配置，但systemd运行服务时不会加载用户shell的自定义环境变量：

• 在服务文件中显式配置必要的环境变量，避免dotnet找不到运行时路径：
  • 添加Environment="DOTNET_ROOT=/usr/share/dotnet"，指定.NET运行时的实际安装路径
  • 添加Environment="PATH=/usr/bin:/usr/share/dotnet"，确保dotnet命令能被正常检索
• 排查时可以先执行sudo systemctl cat 你的服务名，查看系统实际加载的服务配置；再切换到服务指定的运行用户（比如sudo -u www-data bash），在配置的工作目录下手动执行和ExecStart完全一致的命令，能快速复现环境、权限类的问题。

内容的提问来源于stack exchange，提问作者st78