我目前正尝试按照本教程在 Azure 上的 Ubuntu16.04 虚拟机上部署 DotNetCore 应用程序: https://learn.microsoft.com/en-us/aspnet/core/publishing/linuxproduction
将 dotnet publish 生成的文件夹的内容部署到 vm 之后....如果我手动进入项目文件夹并通过 dotnet app_name.dll 启动 Kestrel >，它运行良好，我能够从浏览器访问该应用程序。
手动运行 dotnet app_name.dll 后我从终端得到的输出是
托管环境:生产
内容根路径:/home/myUser/publish
现在正在收听:http://localhost:5000
申请开始。按 Ctrl+C 关机。
现在，教程要我使用 SystemD 来管理 Kestrel 进程。
它通过以下方式为我们运行 dotnet
ExecStart=/usr/bin/dotnet/var/aspnetcore/app_name.dll。在服务文件中
当我启动该服务时，它看起来会正常工作。我得到:
托管环境:生产
内容根路径:/
现在正在收听:http://localhost:5000
申请开始。按 Ctrl+C 关机。
...但是当我尝试访问该应用程序时，kestrel 从未收到请求。我看到两者之间的唯一区别是 Content root path。
现在，在项目中，路径在 startup.cs 中被引用:
公共(public)启动(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath ....
我尝试对字符串值进行硬编码，但这实际上并没有改变任何东西......
那么，我的网络应用程序无法在 systemD 下运行的罪魁祸首是 Content root path 吗？
如果是这样，我该如何解决？ 如果不是，还有其他我应该注意的问题吗？
最佳答案
在新建 WebHostBuilder 时，您是否正在调用 .UseContentRoot(Directory.GetCurrentDirectory())？
如果是这样，当从 systemd 调用它时，它不会起作用。您会发现，如果删除该行，它将获得正确的 ContentRoot。
编辑:
跟进 Arthur's补充回答:是的，您可以在 systemd 配置中指定 WorkingDirectory 作为替代解决方案。您需要做什么取决于您的具体要求和环境。
请记住:
如果未设置 WorkingDirectory，它“当 systemd 作为系统实例运行时默认为根目录，如果作为用户运行则默认为相应用户的主目录。”
如果设置了 WorkingDirectory 但未设置 RootDirectory，“则 WorkingDirectory= 相对于运行服务管理器的系统的根。”
“请注意，设置此参数可能会导致将其他依赖项添加到单元中。” (如目录存在)
关于ubuntu - 在 Ubuntu16.04 上使用 systemD 时 DotnetCore 内容根路径发生变化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41052866/