dotnet / vscode-csharp

Official C# support for Visual Studio Code
MIT License
2.85k stars 667 forks source link

OmniSharp does not respect `files.exclude` #1694

Open firelizzard18 opened 7 years ago

firelizzard18 commented 7 years ago

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.0-preview2-006497)

Product Information:
 Version:            2.0.0-preview2-006497
 Commit SHA-1 hash:  06a2093335

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25407-01
  Build    : 40c565230930ead58a50719c0ec799df77bddee9

VS Code version: Code 1.14.2 (cb82febafda0c8c199b9201ad274e25d9a76874e, 2017-07-19T23:34:09.706Z) C# Extension version: csharp|ms-|1.11.0

Steps to reproduce

Open VSCode on a directory that has projects (mine are in subfolders) that are excluded by files.exclude (I'm doing it from .vscode/settings.json).

Expected behavior

OmniSharp does not try to process projects within excluded folders.

Actual behavior

OmniSharp tries to process projects within excluded folders.

Other Details

I'm transitioning a large project (50+ libraries, 5+ apps) from MSBuild (Visual Studio) to dotnet (VSCode). I have configured VSCode to ignore all the projects that have not been transitioned yet. OmniSharp is trying to process the un-transitioned projects.

DustinCampbell commented 7 years ago

Thanks for the request. This is a good feature request.

nihique commented 6 years ago

+1

sequitur commented 6 years ago

Right now my "problems" panel on a C# project has well over 99 problems (no literally), all of them in vendor code, which renders the feature kind of useless. Is there a workaround or another configuration I can change to prevent this from happening?

joopscheer commented 6 years ago

Having the same problems as @sequitur. In the settings.json the "obj" and "bin" directories are in the "files.exclude" section. However the generated AssemblyInfo.cs files are still analysed. This results in warnings like "Unnecessary using directive.'.

DustinCampbell commented 6 years ago

Having the same problems as @sequitur. In the settings.json the "obj" and "bin" directories are in the "files.exclude" section. However the generated AssemblyInfo.cs files are still analysed. This results in warnings like "Unnecessary using directive.'.

One option is to set the csharp.suppressHiddenDiagnostics setting to true. This will keep diagnostics that are "hidden", such as remove unnecessary usings, from displaying in the editor and the problems pane. That means that remove unnecessary usings also won't squiggle in open files, but the light bulb will still be available to use.

I should mention that this particular feature request is about using files.exclude to help inform the projects that OmniSharp processes. It isn't about getting it to somehow ignore files in processed projects that might contain files that belong to the project. OmniSharp will always process files in "obj" because MSBuild will use it when processing the project. Ignoring files in "obj" could introduce errors in other files for certain project types.

ghandmann commented 6 years ago

Is there any progress so far with this? Currently this issue renders VS Code useless for me, since the whole IntelliSense is broken down, because of one subproject. Quite frustrating.

rchande commented 6 years ago

@ghandmann This is being worked on in https://github.com/OmniSharp/omnisharp-vscode/pull/2171

andrewbusch7 commented 4 years ago

I see #2171 has been merged in, yet I'm still facing the same issue: OmniSharp is trying to load a .Net Framework project for which I've explicitly excluded the .csproj of.

kaleidawave commented 4 years ago

Any updates on this. I am working on a WPF project and OmniSharp is currently telling all my classes have already be implemented as it is scanning the obj folder.

Saltallica commented 4 years ago

Agreed - very annoying.

mrjohnr commented 4 years ago

same problem here using Local history extension that creates .history folder inside project root,need a way to exclude it.thanks

rickvanprim commented 4 years ago

It looks like this can be done separately through an omnisharp.json file in the root of the workspace: https://github.com/OmniSharp/omnisharp-roslyn/wiki/Configuration-Options#file-options

mrjohnr commented 4 years ago

I have no default omnisharp.json file in VsCode/user data,I've placed one in my project folder but not working :(

dotaxis commented 4 years ago

It looks like this can be done separately through an omnisharp.json file in the root of the workspace: https://github.com/OmniSharp/omnisharp-roslyn/wiki/Configuration-Options#file-options

Those settings don't do anything. I've tried all combinations of where to place the file and which settings to use.

filipw commented 4 years ago

it controls solutions/project file discovery, not individual cs files.

dotaxis commented 4 years ago

Can we get something that ignores individual .cs files then? Or rather, files of any type?

Or just get OmniSharp to respect files.exclude?

filipw commented 4 years ago

that is a csproj project file feature https://stackoverflow.com/a/43219140

OmniSharp is only concerned with finding sln/csproj file to start with, after that MSBuild is responsible for processing everything

dotaxis commented 4 years ago

Clearly I don't understand as well as I thought I did. I apologize.

Is it out of the question to have an override in OmniSharp that at least ignores errors in specified files/folders? Does that functionality exist already?

When I use external libraries I get hundreds of messages about stuff like naming conventions, 'can be readonly', etc. Certain VSCode extensions (like Local History) break OmniSharp entirely if they place files within the workspace.

I'm not sure how manually editing solution/project files would affect the build process, but either way I feel like it shouldn't be necessary.

hsnabn commented 4 years ago

Leaving a comment in case anyone ends up here from Google (this is the top result when I search 'vscode c# ignore folder':

I managed to get the analyzers to ignore folders/files thru using .editorconfig (might need to enable it in vscode c# settings): Microsoft Docs reference for analyzers

[Folder/**.cs]
generated_code = true

Telling omnisharp that it's generated code seems to keep it from analyzing.

(Unfortunately in my case the folder I wanna exclude is an outside library source which I wanna ignore; unfortunately they have their own .editorconfig with root = true and mine's getting overridden. That's another problem though.)

kinosang commented 4 years ago

I have "/artifacts" in files.exclude, and have set generated_code = true for `[artifacts/.cs]in my.editorconfig, but OmniSharp still reports errors fromartifacts/obj/**.cs`.

samlletas commented 4 years ago

I can confirm as well that .editorconfig file as suggested doesn't work for me in vscode, errors are still reported.

Edit: My bad, turns out I just needed to enable "omnisharp.enableEditorConfigSupport": true in vscode settings.json, errors are not reported anymore.

For reference, here is my .editorconfig contents:

[Assets/ProCamera2D/**.cs]
generated_code = true

[Assets/Tayx/**.cs]
generated_code = true
felipesdias commented 3 years ago

I have "/artifacts" in files.exclude, and have set generated_code = true for `[artifacts/.cs]in my.editorconfig, but OmniSharp still reports errors fromartifacts/obj/**.cs`.

I have the same problem

behnood-eghbali commented 3 years ago

Solution: Before debugging, add the following lines to each of the *.csproj files within the <PropertyGroup> section:

    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
    <GenerateAssemblyInformationalVersionAttribute>false</GenerateAssemblyInformationalVersionAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
    <GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
    <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
    <GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>

Screenshot from 2021-03-09 21-58-21

kazinad commented 3 years ago

I experience the followings:

  1. You need to have both a) omnisharp.json b) .editorconfig
  2. omnisharp.json fileOptions must have excludeSearchPatterns setting only, remove systemExcludeSearchPatterns completely if you have that one.
  3. you have to enable omnisharp.enableEditorConfigSupport setting, as mentioned above.

Update: the above only work as long as there is no compilation error. After the first compilation error, omnisharp.json settings are ignored and it discovers those files too.

fgimian commented 3 years ago

I hope everyone is doing well. I personally have not had any luck with any of the approaches mentioned so far.

This all started when I configured unused using statements to be warnings (as I was missing them in my own code).

Here's what I added to my .editorconfig:

# Ensure that unused using statements are treated as warnings.
dotnet_diagnostic.CS8019.severity = warning

Now, OmniSharp is complaining about unused imports in various *.cs files in the obj\Debug directory of my project.

So I created an omnisharp.json at the root of my project with the following contents:

{
  "fileOptions": {
    "excludeSearchPatterns": ["**/obj/**/*"]
  }
}

Just for fun, I also tried the systemExcludeSearchPatterns setting with the same pattern.

I also added the following to my .editorconfig:

[**/obj/**/*.cs]
generated_code = true

I also tried this variant:

[**/obj/**.cs]
generated_code = true

But sadly, I continue to see these warnings in my PROBLEMS tab.

Has anyone gotten this working for *.cs files in their obj directory?

Thanks heaps Fotis

DasOhmoff commented 2 years ago

I have this same issue. Are there any news on this?