我正在尝试按照本教程在Azure上的Ubuntu16.04 vm上部署DotNetCore应用程序： https://docs.microsoft.com/en-us/aspnet/core/publishing/linuxproduction
将dotnet publish生成的文件夹的内容部署到vm ....如果我手动进入项目文件夹并通过dotnet app_name.dll启动Kestrel，它运行正常，我能够从浏览器访问该应用程序。
手动运行dotnet app_name.dll后我从终端获得的输出是
Hosting environment: Production
Content root path: /home/myUser/publish
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
现在，本教程希望我使用SystemD来管理Kestrel进程。
它通过我们运行dotnet
ExecStart=/usr/bin/dotnet /var/aspnetcore/app_name.dll。在服务文件
当我启动服务时，看起来它会起作用。我明白了：
Hosting environment: Production
Content root path: /
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
...但是当我尝试访问应用程序时，kestrel永远不会得到请求。我在两者之间看到的唯一区别是Content root path。
现在，在项目中，在startup.cs中引用了路径：
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath ....
我尝试对字符串值进行硬编码，但实际上并没有改变任何内容......
那么，我的网络应用程序的罪魁祸首是不能在systemD Content root path下工作吗？
如果是这样，我该如何解决这个问题？ 如果没有，是否还有其他问题需要注意？
答案 0 :(得分：3)
在新建WebHostBuilder时，您是否正在调用.UseContentRoot(Directory.GetCurrentDirectory())？
如果是这样的话，从systemd调用它时就无法运行。您会发现如果删除该行，它将获得正确的ContentRoot。
修改
要跟进Arthur's补充答案：是的，您可以在systemd配置中指定WorkingDirectory作为备用解决方案。您需要做的是取决于您的具体要求和环境。
请记住：
如果未设置WorkingDirectory，则“当systemd作为系统实例运行时，默认为根目录，如果以用户身份运行，则默认为相应用户的主目录。”
如果设置了WorkingDirectory但未设置RootDirectory，则“WorkingDirectory =相对于运行服务管理器的系统的根目录。”
“请注意，设置此参数可能会导致将其他依赖项添加到设备中。” （例如现有的目录）
答案 1 :(得分：2)
问题是Directory.CurrentDirectory()返回运行dotnet命令的目录。解决此问题的最简单方法是通过添加以下行来修改systemd配置文件：
WorkingDirectory=/var/aspnetcore
这会更改执行dotnet命令的目录。这样您就不必更改项目的代码，它在本地计算机上的工作方式与在远程计算机上的工作方式相同。