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
Each error appears only once in output window
Errors are duplicated.
Edit tasks.json to disable the summary:
"tasks": [
{
"taskName": "build",
"args": [
"${workspaceRoot}\\qqq.csproj",
"/clp:NoSummary"
],
"isBuildCommand": true,
"problemMatcher": "$msCompile"
}
]
Visual Studio arranges not to duplicate errors in its output windows, but VS Code does not.
Related: dotnet/sdk#823, dotnet/cli#5607
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?
I think we want to fix dotnet/cli#5607 and then pass /clp:NoSummary and keep using build.
Makes sense to me!
(Very glad to have you active here this morning @nguerrera :smile:)
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 :)
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.
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

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.
Any news on this? The problem is still present in the latest release of VSCode and the extensions.
Any news on this? The problem is still present in the latest release of VSCode and the extensions.
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?
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.
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.
microsoft/vscode#76318. This is the PR in vscode with the change to the build templates.
This is fixed in both the extension and in vscode side, and will be available in the next releases.
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?

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"
}
]
}
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"
}
]
}
@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.


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"
}
]
}
@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").
https://github.com/microsoft/vscode/issues/98633
In the meantime, is there anyway to suppress Omnisharp from generating these problem reports? I just want to see the actual build errors.
@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.
@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.
Most helpful comment
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 Summaryparameter: