"Go to type" tool includes .g.i.cs files, should not

[vsfeedback]

When I use the "go to type" tool ("Ctrl+,", then search for "t <typename>"), it's finding hits in .g.i.cs files. That probably shouldn't happen. See screen shot.

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/74648/go-to-type-tool-includes-gics-files-should-not.html VSTS ticketId: 457985 These are the original issue comments:

Stephen Watkins on 10/1/2017, 08:45 PM (204 days ago):

This is slightly more of a pain than originally stated -- more than just cluttering search results, these .g.i.cs files frequently stay open in a "preview" tab somewhere in the tab well (even after I have confirmed another file from the results list), and then cause "this file has been changed externally" dialogs to show up whenever I build my code. Every time I search for something using Edit.GoToAll, which is extremely often, I have to go make sure there are no spurious preview tabs left open.

masahiko miyasaka on 10/16/2017, 11:35 PM (189 days ago): Agree. When I use Ctrl+T search, this happens so often.This is incredibly stressfull.OK ,sometime it'may be necessary to see auto-generated file to check somthing, but it shoudn't be happen by default. Daniel Nordström on 11/8/2017, 02:57 AM (167 days ago):

I have this problem to, what is worse is that they always is on top in the result as well.

Anton Zimin on 11/23/2017, 11:20 PM (151 days ago):

The issue persists in VS 15.4.4.

Daniel Møgelgaard Pedersen on 4/20/2018, 07:50 AM (4 days ago):

This is really annoying in large solutions where you rely on "ctrl+," Find Tool to find files, as the g.i.cs files are often at the top of a result list and you can't see which are g.i.cs files and which aren't.
This has been an issue since launch. I don't understand what there is to 'Investigate' as it is a pretty straight forward problem.
The issue persists in VS 15.5.4.

These are the original issue solutions: (no solutions)

[CyrusNajmabadi]

Somewhat of a dupe of https://github.com/dotnet/roslyn/issues/14930

Note: an easy mitigation is to attempt to sort these files better. Note: i do think it's valuable to have these items. I know i like going to the real .g source to figure out what's going on and what's actually being generated.

[omanuke]

How do u think about having an option like a checkbox to include those files or not?

[Solethia]

I am not sure how other people work with the "Go To Find Tool" but in my team it is rare that we need to consult the generated file (in our case g.i.cs). I have not studied the implementation of the "Go To Find Tool" so I'm not sure what is best in line with the current implementation and design ideal. For our team either having them always sorted later than the file they are generate from or simply having them only show up if you search specifically for them e.g. "SomeFile.g.i.cs" would be sufficient for our use-case but that might interfere with how others use the tool so more input or an explicit choice (checkbox) might be better.

Checkbox in settings wouldn't be too invasive.

Also some of the complaint goes on that in the list of results you can't really differentiate whether a file is the g.i.cs file or a .cs file as they have the same icon and coloring (theme). This is not addressed in the solutions mentioned above. A specific theme for generated files might alleviate a lot of the problems too.

[CyrusNajmabadi]

How do u think about having an option like a checkbox to include those files or not?

Yes, that's def something that could be considered. "Include generated code" would def make sense as an option.

[CyrusNajmabadi]

but in my team it is rare that we need to consult the generated file (in our case g.i.cs).

It's my personal preference to look there myself. :D

Note: we already have smarts for how we sort results. For example, if you have results in both "SomeType.vb" and in "SomeType.Nested.vb" we'll sort the former results above the latter results even though the latter file name is lexicographically before the former file name. This is so searches for 'SomeType' don't sort the other partial types above the main type.

We could def do something similar here for .g.i.cs

[Solethia]

Note: we already have smarts for how we sort results. ... We could def do something similar here for .g.i.cs

I think the above solution is sufficient to remove most of the annoyance. There is a secondary problem with the way content from different content are displayed in the search output as mentioned by Anton Zimin. If this problem is addressed by sorting differently, it would still be 'nice' to be able to differentiate between content in .cs files and .g.i.cs files (or similar generated files) in the search output.

A possible solution would be to style .g. files differently or somehow displaying the full file ending when showing classes in the output, but i guess then it would lose the abstraction of just outputting 'class' information for class items in the search output.

Either way sorting generated files last would be an improvement.

[Sebastian-Franz]

Any progress here?

You could add a new search option, that includes hidden files - if someone really cares about them.

[CyrusNajmabadi]

@Sebastian-Franz this is on the backlog. It's not being looked at ahead of any scheduled work. If you're interested in improving things here, we would take a community pr though. I outlined above a viable strategy we would likely take.

Thanks!

[DaveInCaz]

FWIW there is a Stack Overflow question asking about this same issue.

[Matiquiel]

If you just show g.i.cs files BELOW the actual useful files for most people that will solve the issue. Current problem is that the first item shown is the g.i.cs which is the file you don't wanna navigate to 99.9% of the times.

I think files from obj folders should be ignored altogether by default with the possibility to include them

[szalapski]

This is a really inconvenient think that is getting much less attention than it deserves, and it strikes me that the fix is easy and obvious. Could someone take a look to prioritize it? This is the only thing keeping me using Resharper routinely (for its Ctrl+T find that already does this).

[CyrusNajmabadi]

@szalapski see: https://github.com/dotnet/roslyn/issues/26369#issuecomment-1026987787

[dvygolov]

Sad that after 5(!) years after this topic started, this thing is still not implemented :-(

[CyrusNajmabadi]

Sad that after 5(!) years after this topic started, this thing is still not implemented :-(

@dvygolov fortunately, Roslyn is open source :-). So if you're interested in improving things here, you can always contribute a pr. Thanks!