Errors are duplicated in output window

[nguerrera]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc4-004769)

Product Information:
 Version:            1.0.0-rc4-004769
 Commit SHA-1 hash:  9cf4e9d1d0

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0-rc4-004769

VS Code version: 1.9.0
C# Extension version: 1.6.2

Steps to reproduce

• dotnet new console
• dotnet restore
• Edit program.cs and make a deliberate error
• code .
• Ctrl+Shift+B
• Configure build task -> .NET Core
• Ctrl+Shift+B again
• Look at output window

Expected behavior

Each error appears only once in output window

Actual behavior

Errors are duplicated.

Workaround

Edit tasks.json to disable the summary:

 "tasks": [
        {
            "taskName": "build",
            "args": [
                "${workspaceRoot}\\qqq.csproj",
                "/clp:NoSummary"
            ],
            "isBuildCommand": true,
            "problemMatcher": "$msCompile"
        }
]

Notes

Visual Studio arranges not to duplicate errors in its output windows, but VS Code does not.

Related: dotnet/sdk#823, dotnet/cli#5607

[DustinCampbell]

Hmmm... I'm not sure of switching over to "dotnet msbuild" as it might have other ramifications.

@piotrpMSFT: will there be other fallout if we do this? E.g. will we break "dotnet build" telemetry?

[nguerrera]

I think we want to fix dotnet/cli#5607 and then pass /clp:NoSummary and keep using build.

[DustinCampbell]

Makes sense to me!

(Very glad to have you active here this morning @nguerrera 😄)

[nguerrera]

Turns out that dotnet build [project] /clp:NoSummary works fine.

The issue is with dotnet build /clp:NoSummary (implicit project). So, I think you can fix this without blocking on dotnet/cli#5607 :)

[AndrewTriesToCode]

Just want add that I am still seeing this problem. I am using the 2.1-preview1 SDK, VS Code 1.21.0, omnisharp-vscode 1.15-beta1 on MacOS High Sierra.

If I run dotnet build /clp:NoSummary at my solution root, no summary is shown. In VS Code if I run the build task with the same command, each error is duplicated in the output window. If I fix the error one of the 2 errors goes away, but the other persists until I rebuild.

[ThisDevDane]

The same as @achandlerwhite is happening to me, it seems to be because omnisharp only show the csproj name while dotnet build shows the entire path

[RichardD012]

To add to this, my experience is slightly off. I get the build error correctly once. When I click on the problems view, I click the problem, get the "Unable to open ..." popup and then a duplicate is created. I am able to click to duplicate and it takes me to the file in the workspace.

The initial view that shows the unable to open popup has a source of "/" beside the file name. When the duplicate that works is created, the correct subdirectory of where that file exists is shown beside the file name.

[ThisDevDane]

Any news on this? The problem is still present in the latest release of VSCode and the extensions.

[ramarivera]

Any news on this? The problem is still present in the latest release of VSCode and the extensions.

[xcap2000]

Using /clp:NoSummary works for me even without pointing to a project file. The issue is that I cannot use it for all commands I am used to use. Is there a way to add this option to the csproj? Before I used a command to avoid error when clicking on items on the PROBLEMS list, it was GenerateFullPaths and set it to true.
I am using dotnet core preview 5 and visual studio extension version 1.20.0.
@nguerrera should this item be reopened?

[nguerrera]

Using /clp:NoSummary works for me even without pointing to a project file.

Yes, that was fixed a long time ago in CLI.

The issue is that I cannot use it for all commands I am used to use.

Do you mean that there are cli commands that do not work with /clp:NoSummary, or just that you don't want to pass it every time?

Is there a way to add this option to the csproj?

Unfortunately, no.

But we have talked about a cli config system that would let you configure things like this per user or per directory

Should this item be reopened?

Which item? This issue is not closed.

[xcap2000]

Yes, that was fixed a long time ago in CLI.
-> Perfect!
Do you mean that there are CLI commands that do not work with /clp:NoSummary, or just that you don't want to pass it every time?
-> Tried with dotnet watch run, no errors but no success, maybe it is because it does not return unless we cancel the task.
Unfortunately, no.
-> Thank you for clarifying.
Which item? This issue is not closed.
-> My bad, sorry for that.

[akshita31]

microsoft/vscode#76318. This is the PR in vscode with the change to the build templates.

[akshita31]

This is fixed in both the extension and in vscode side, and will be available in the next releases.

[ghristov88]

I am still experiencing the same problem after I followed the 'Steps to reproduce' of @nguerrera. I am on the latest version of vscode (1.38.1) and on the latest update on the C# extension (1.21.2), but I still have the errors duplicated. When I fix the deliberate error, the first line in the problems pane disappears almost immediately, but the second disappears only after I build the project. Is this a normal behaviour or maybe I have something misconfigured on the OmniSharp extension?

Here is some information about my setup:

---

dotnet --info

.NET Core SDK (reflecting any global.json):
 Version:   2.2.300
 Commit:    73efd5bd87

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.300\

Host (useful for support):
  Version: 2.2.5
  Commit:  0a3c9209c0

vscode version

Extension version

Name: C#
Id: ms-vscode.csharp
Description: C# for Visual Studio Code (powered by OmniSharp).
Version: 1.21.2
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp

task.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "command": "dotnet",
            "type": "process",
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "args": [
                "build",
                "${workspaceFolder}/TestVsCodeErrorDuplications.csproj",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        }
    ]
}

[crispyricepc]

Hi, this bug is still present on my system. Current version is 1.40:

Similar to the person above, my build task includes the No Summary parameter:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "command": "dotnet",
            "type": "process",
            "args": [
                "build",
                "${workspaceFolder}/Chess.csproj",
                "/property:GenerateFullPaths=true",
                "/clp:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        },
        {
            "label": "publish",
            "command": "dotnet",
            "type": "process",
            "args": [
                "publish",
                "${workspaceFolder}/Chess.csproj",
                "/property:GenerateFullPaths=true",
                "/clp:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        },
        {
            "label": "watch",
            "command": "dotnet",
            "type": "process",
            "args": [
                "watch",
                "run",
                "${workspaceFolder}/Chess.csproj",
                "/property:GenerateFullPaths=true",
                "/clp:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        }
    ]
}

[toptensoftware]

@akshita31 this appears to still be broken in latest vscode/addin even with a basic setup and is not a great out of the box experience.

1. mkdir testerrs
2. cd testerrs
3. dotnet new console
4. code .
5. delete the semicolon of the end of the WriteLine("Hello World") line
6. Build - one error in terminal, two in problems panel.

tasks.json is the automatic one created by VS Code:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "command": "dotnet",
            "type": "shell",
            "args": [
                "build",
                // Ask dotnet build to generate full paths for file names.
                "/property:GenerateFullPaths=true",
                // Do not generate summary otherwise it leads to duplicate errors in Problems panel
                "/consoleloggerparameters:NoSummary"
            ],
            "group": "build",
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": "$msCompile"
        }
    ]
}

[toptensoftware]

@akshita31

The cause of this problem is that the build task and the roslyn code analysis are both reporting the same issue. I've lodged a feature request against VS Code for the ability to filter the Problems panel by the problem owner (ie: "csharp" vs "msCompile").

microsoft/vscode#98633

In the meantime, is there anyway to suppress Omnisharp from generating these problem reports? I just want to see the actual build errors.

[xcap2000]

@toptensoftware @akshita31 I would rather have the messages from Omnisharp than from the build task, if you click on an Omnisharp generated error it selects the problem in a better way than the error generated by the build task. I thought about a way of "merging" the messages from both sources but it turns out that even though we use the correct configurations (GenerateFullPaths) the messages do have some differences. @toptensoftware I understand that is not your proposal for a final solution though.

[toptensoftware]

@xcap2000

I would rather have the messages from Omnisharp

For some situations I agree but right now I'm doing a large refactoring and I just want to get a particular sub-project to build before moving onto the next. The Omnisharp generated errors are saturating the problem panel with issues that I'm not ready to deal with them yet. I can work around it by ignoring those projects with omnisharp.json, but that's painful with a lot of sub-projects.

Another situation: some of my projects have platform independent versions. eg: subproject.win.csproj, subproject.osx.csproj and subproject.gtk.csproj. If I switch from working on one platform to another (for the purposes of getting it to build I'll work on all three on under Windows), I have to edit omnisharp.json to ignore the projects that aren't applicable for the current platform. If I don't do that Omnisharp freaks out with out thousands of errors - making the problems panel completely useless.

To explain what's happening here. With these platform specific projects I'll have a set common of files and a set of per-platform files. The platform specific files will be in sub-folders "PlatformWin", "PlatformOsx" etc... and each are a partial class providing the platform implementation part of the common class file. The .win.csproj file is configured to only include PlatformWin, similar for the other platforms. Omnisharp really doesn't like this and generates 3 errors for every per-platform partial method that its multiply defined..

Granted, I might be in a bit of a unique situation with the above but being able to either filter the problems panel by problem owner, or being able to configure Omnisharp to stop putting stuff in the problem panel would help immensely.

Another way of saying all of the above - by being able to limit the problems panel to just stuff from the current build it can react to the selected build task configuration and let me focus on what I'm working on.

[rjgotten]

FWIW: It's now 2021 and I still get errors duplicated between Ominsharp and the build task's $msCompile problem matcher.
I've had to take drastic measures and just flat out cut the problem matcher from the task.json configuration altogether, as nothing else seems to work.

I'd rather lose compile-time errors than real-time reporting and the compile-time errors are a major annoyance anyway, because they stick around long after the file has been modified and require that the build task actually be re-run to clear out.

[soulflyman]

I also have duplicated Messages in the Problem tab with v1.66.0.
My tasks.json looked like this:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build debug",
            "command": "dotnet",
            "type": "shell",
            "args": [
                "build",
                // Ask dotnet build to generate full paths for file names.
                "/property:GenerateFullPaths=true",
                // Do not generate summary otherwise it leads to duplicate errors in Problems panel
                "/consoleloggerparameters:NoSummary"
            ],
            "group": "build",
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": "$msCompile"
        },
    ]
}

Changing the property GenerateFullPaths to false fixed it for me and I only see omnisharp error messages and no longer the compile-time errors.

[geekley]

I'm also getting duplicate warnings like everyone.
@akshita31 please reopen, as this issue is not solved by the "-clp:NoSummary".

[josephemorgan]

Just commenting to add that I've been spending days trying to solve this, hunting around on discord, stack overflow, making reddit posts, etc. and I haven't been able to get rid of the duplicate errors.

Problem matcher is essentially the same as what everyone else has posted.