Warnings/Errors from compile return paths relative to the project file. #823
Comments
|
It took me a second to find the Expected v. Actual behavior, so thought I'd share. ExpectedSource file paths are shown relative to the PWD in which build was started ActualSource file paths are shown relative to the directory containing the project, making the navigation to a source file a two-step process [look at the fully qualified project path, then figure out the relative path to the soruce file] |
|
This has been standard msbuild/csc behavior for a long time. Here's a test with bits from Visual Studio 2015 and a .NET Framework console app project: There is a GenerateFullPaths option on the Csc task corresponding to csc /fullpaths argument and so +@DustinCampbell re: not being able to double click in VS Code. |
|
I was hoping there was a flag... I'm kinda curious why that's not a default, given that it's necessary to identify the file when building an .sln with more than one project file. What tools are y'all actually using to write code? |
|
While I'm here, is there a way to only get the errors written to the console just once? It's printing them twice, once during the build, and once at the end. Which causes duplicates in VScode : |
|
The warnings are showing twice because the CLI passes /clp:Summary to msbuild: I thought As a workaround, you can use raw
|
|
Closing as it is by design that the SDK has no opinion or impact on how compilation errors are formatted. That is up to whoever is launching msbuild. I've filed linked bugs in CLI and omnisharp-vscode to improve the default experience. |
|
I'm able to add '/clp:NoSummary' to the gulp command that's calling dotnet build and it's doing the right thing. 👍 I've also added We're good to go! |
|
Ah! It works if you pass the csproj. I think it was considering my /clp:NoSummary as the project arg to go before the rest. |
|
yeah, the default behavior is broken. if you have multiple projects containing different files with the same names, then double-clicking on an error in one file will invariably open the wrong file and navigate to whatever line number in that file leaving the user completely confused - 'there's no such error here!' the default should always be full paths. |
This happens in Visual Studio too! |
…0190731.1 (dotnet#823) - Microsoft.AspNetCore.Mvc.Analyzers - 3.0.0-preview9.19381.1 - Microsoft.AspNetCore.Mvc.Api.Analyzers - 3.0.0-preview9.19381.1 - Microsoft.AspNetCore.Analyzers - 3.0.0-preview9.19381.1 - Microsoft.AspNetCore.Components.Analyzers - 3.0.0-preview9.19381.1
Steps to reproduce
I have a solution with many projects.
If I build the .sln file from the cmdline:
The errors/warnings are printed to the console with their 'project-local' path .
I can't click on the errors in VSCode, because they don't have the full path (or the path relative to the .sln folder)
These lines should give be include the full path:
Environment data
The text was updated successfully, but these errors were encountered: