Omnisharp在使用docker时会自动崩溃

Question

我在docker中运行basic dotnetcore example，它工作得很好。一切都构建好了，我的API就可用了。它还监听实时变化，这是完美的。您可以在问题的底部找到Dockerfile和docker-compose。

然而，我试图使用Visual-studio-code (insiders和regular)结合omnisharp (默认的c#扩展)来处理代码，但它总是在我身上崩溃。

它会工作几秒钟，然后继续给我180+“问题”，所有这些都是假的(这个应用程序可以工作..)

输出没有指示任何imo (从重新启动到崩溃)：

Starting OmniSharp server at 7/3/2018, 11:52:55 AM
    Target: /home/mastermindzh/code/

OmniSharp server started
    Path: /home/mastermindzh/.vscode-insiders/extensions/ms-vscode.csharp-1.15.2/.omnisharp/1.30.1/run
    PID: 2323

[info]: OmniSharp.Stdio.Host
        Starting OmniSharp on arch 0.0 (x64)
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Located 1 MSBuild instance(s)
            1: StandAlone 15.0 - "/home/mastermindzh/.vscode-insiders/extensions/ms-vscode.csharp-1.15.2/.omnisharp/1.30.1/omnisharp/msbuild/15.0/Bin"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        MSBUILD_EXE_PATH environment variable set to '/home/mastermindzh/.vscode-insiders/extensions/ms-vscode.csharp-1.15.2/.omnisharp/1.30.1/omnisharp/msbuild/15.0/Bin/MSBuild.dll'
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Registered MSBuild instance: StandAlone 15.0 - "/home/mastermindzh/.vscode-insiders/extensions/ms-vscode.csharp-1.15.2/.omnisharp/1.30.1/omnisharp/msbuild/15.0/Bin"
            MSBuildExtensionsPath = /home/mastermindzh/.vscode-insiders/extensions/ms-vscode.csharp-1.15.2/.omnisharp/1.30.1/omnisharp/msbuild
            BypassFrameworkInstallChecks = true
            CscToolPath = /home/mastermindzh/.vscode-insiders/extensions/ms-vscode.csharp-1.15.2/.omnisharp/1.30.1/omnisharp/msbuild/15.0/Bin/Roslyn
            CscToolExe = csc.exe
            MSBuildToolsPath = /home/mastermindzh/.vscode-insiders/extensions/ms-vscode.csharp-1.15.2/.omnisharp/1.30.1/omnisharp/msbuild/15.0/Bin
[info]: OmniSharp.Cake.CakeProjectSystem
        Detecting Cake files in '/home/mastermindzh/code/'.
[info]: OmniSharp.Cake.CakeProjectSystem
        Could not find any Cake files
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Initializing in /home/mastermindzh/code/
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Auto package restore: False
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Update workspace context
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Resolving projects references
[info]: OmniSharp.MSBuild.ProjectSystem
        No solution files found in '/home/mastermindzh/code/'
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/home/mastermindzh/code//api/api.csproj'
[info]: OmniSharp.Script.ScriptProjectSystem
        Detecting CSX files in '/home/mastermindzh/code/'.
[info]: OmniSharp.Script.ScriptProjectSystem
        Could not find any CSX files
[info]: OmniSharp.Stdio.Host
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
[info]: OmniSharp.Stdio.Host
        Configuration finished.
[info]: OmniSharp.Stdio.Host
        Omnisharp server running using Stdio at location '/home/mastermindzh/code/' on host 30096.
[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /home/mastermindzh/code//api/api.csproj
[info]: OmniSharp.MSBuild.ProjectManager
        Adding project '/home/mastermindzh/code//api/api.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Update project: api

在这之后，这个扩展就不能工作了，直到我重新启动它，它又崩溃了。这只在Docker中启动或从cli启动时才会失败，如果我通过vscode运行应用程序(这是我不想做的事情)，它可以正常工作。

Dockerfile：

FROM microsoft/dotnet:2.1-sdk-stretch
WORKDIR /app
EXPOSE 5000
CMD dotnet restore && dotnet watch run

撰写：

version: "3"
services:

    web:
        build:
            context: ./../../api
            dockerfile: ./../docker/images/api/Dockerfile
        ports:
            - "5000:5000"
            - "5001:5001"
        volumes:
            - ./../../api/:/app
        depends_on:
             - db

到目前为止，我最好的猜测是它与dotnet恢复和/或bin/obj文件夹有关。干净利落地运行dotnet，然后启动应用程序没有什么区别。

任何帮助都将不胜感激。

Answer 1

嗨，瑞克，你能解决这个问题吗？我遇到了同样的问题，试图在docker容器中使用Omnisharp扩展来运行调试器。

我看到你提到的那些bin/obj引用，这似乎是由于.net如何配置运行时环境。这似乎是基于dotnet共享文件夹的位置。这篇文章解释了其中的一部分：What is the purpose of msbuild's GenerateRuntimeConfigurationFiles?

我认为问题在于这个共享文件夹不同于实际的主机(我正在运行的机器)而不是docker容器上的内容。因此，当您在容器中运行dotnet时，它会根据容器中的内容配置运行时。这会抛出Omnisharp，因为它在容器之外运行。

我认为我们可以定义并卷挂这些共享文件夹作为dockerfile (或docker-compose)的一部分。但是我还没有让一些东西起作用。我知道这是几个月前的事了，但如果你弄明白了。谢谢!

Answer 2

我有最新消息。如果你还在做这件事，也许这会有所帮助。

因此，正如我在上一篇文章中所提到的，问题是您的VSCode调试器在docker容器之外运行。您需要的是在该容器中启动远程调试器，然后将VSCode附加到该容器中。

我遵循了这里发布的一个示例。这是一个控制台应用程序。https://github.com/sleemer/docker.dotnet.debug

我为webapi和mvc应用程序扩展了上面的示例。你可以在这里看到：https://github.com/johnlee/dockerdotnetcorevscode

我也有一篇关于它的文章，尽管它主要是我自己的笔记，所以可能不是最容易阅读的。https://solidfish.com/building-net-core-apps-docker-with-vscode-on-mac-or-windows/

您的另一个选择是在docker容器中实际运行VSCode。这可能有点夸大其词，但似乎是可能的。https://www.aaron-powell.com/posts/2017-09-21-vscode-linux-docker-windows/

Answer 3

我设法找到了一种配置，使其在使用“带docker compose的映射项目文件夹+ dotnet监视”的工作流程时变得可行，它可以实时更新代码，而不必每次都重新构建容器。

首先，我将发布完整的docker-compose.yml，然后我将解释必要的配置。

这是.NET项目的完整docker-compose.yml (需要使用VSCode扩展)：

services:
  dotnet-api:
    image: mcr.microsoft.com/dotnet/core/sdk:2.2.402
    command: [sh, -c, "dotnet watch run"]
    working_dir: /app
    volumes:
       - .:/app
       - /usr/bin/dotnet:/usr/bin/dotnet
       - /usr/share/dotnet:/usr/share/dotnet
       - ${HOME}/.nuget:${HOME}/.nuget
    environment:
       HOME: /home/${USER}

请注意，我在这里使用的是.NET SDK2.2(因为我维护的是一个遗留应用程序)，但您应该能够根据自己的需要对其进行调整。此外，您可能需要将working_dir变量更改为您的API csproj文件所在的路径，或者指定使用dotnet watch run --project YourProject.API/YourProject.API.csproj运行的项目。

现在，我们将逐步进行解释。

将.NET环境挂载到容器中

VS Code C# extension and omnisharp interact with the omnisharp sdk mainly through the dotnet cli tool的通信，因此您还必须将其映射到您的容器，因此以下代码行：

services:
  dotnet-api:
    volumes:
      - /usr/bin/dotnet:/usr/bin/dotnet
      - /usr/share/dotnet:/usr/share/dotnet

请注意，这将覆盖容器中的sdk，因此您首先会失去使用SDK容器的一点好处。

将当前用户映射到容器$HOME

您还需要将当前用户nuget文件夹映射到omnisharp期望的路径中的容器，该路径为$HOME/.nuget，但仅挂载.nuget文件夹是不够的，因为容器没有设置$HOME变量，如果您不设置该变量，则omnisharp将在根文件夹中查找包，并将失败，因为它没有权限。

因此，您可以添加以下行：

services:
  dotnet-api:
    volumes:
      - ${HOME}/.nuget:${HOME}/.nuget
    environment:
      HOME: /home/${USER}

这应该能够让VS代码的C#扩展停止显示错误，但是使用这种解决方案，调试器可能无法工作，因为您需要附加到正在运行可执行文件的进程，这完全是另一个问题。

即使我改写了容器内部的SDK，它失去了Docker的一些好处，但我仍然喜欢使用docker compose，这样我就可以轻松地启动多个容器，并在必要时尝试新的容器，所以这个配置对我来说仍然是值得的，因为它只在开发环境中使用。