Suggest import statement based on common usage

[YairHalberstadt]

Version Used: VS 16.3 preview

Steps to Reproduce:

I have a project which references many nuget packages. As a result there are at least 4 ILogger interfaces defined.

I have a constructor that takes MyLogging.ILogger.

public class C
{
    public C(ILogger logger){}
}

MyLogging isn't imported, and so I get a code fix to add using statements. However the suggestions only show the top 3 results, which don't include MyLogging.ILogger.

Given how many classes have a constructor accepting ILogger, this is quite annoying.

Would it be possible to sort the using statements to add based on how frequently they're used in the project?

[sharwell]

Another case: https://developercommunity.visualstudio.com/content/problem/1125396/httpmethod-auto-adds-some-internal-kestrel-namespa.html

[sharwell]

Another related case: https://developercommunity.visualstudio.com/t/AmazonRuntimeInternalUtil-is-imported/10356042

The "common usage" determination would apply equally to types from unimported namespaces and suggestions for quick fixes.

[sailro]

Adding a similar case when using Unity: https://developercommunity.visualstudio.com/t/Auto-using-imports-wrong-namespace/10503478

[Draco18s]

Adding a similar case when using Unity: https://developercommunity.visualstudio.com/t/Auto-using-imports-wrong-namespace/10503478

The odd/slightly different thing about this one (see this video) is that a single-line copy-paste automatically added a using statement (in contrast to the reported "MyLogging isn't imported, and so I get a code fix to add using statements") just that it imported the wrong namespace.

Not captured in the video is that if two lines are copy-pasted instead, then the behavior is the same as this report: no import and get a code-fix.

[sharwell]

Another case: https://developercommunity.visualstudio.com/t/Restrict-access-to-Public-classes/10581889

[deangoddard]

Firstly happy to have my case (restrict access...) moved here and my original idea is a bit heavy handed. But I was coming at this from a slightly different approach as the code I'm referencing is my own code, not a 3rd party. And my problem is not with usings but with intellisense and any other popup, real-time assistant that is helping me with what I can do next. So, after thinking about all this...

My idea is I want a black-list text file (per project) that can be checked in with normal source code, which contains a list of fully qualified paths to public items (classes, methods, properties, etc.). Any IDE can read the black-list and hide from the developer any suggestions or meta-info about any of the items in the black-list.

It'll work for the Usings issue above, and anywhere where suggestive code is shown, because only the references you want will be shown. And it doesn't break code, stop you from using the inappropriate reference, or require compiler or language changes.

And further to this, we can use an attribute (similar to say DebuggerStepThrough which serves IDE's) to decorate the code we want to hide. Any IDE like Visual Studio can then automatically add the fully qualified path to the black-list, when referencing an assembly containing the attribute. For example BlackListAttribute() will automatically black-list the decorated public item when the assembly is consumed.

Then we can do BlackListOutsideOf("MyBizNamespace"), so that Visual Studio will display the decorated public item for projects within that namespace (ie: "MyBizNamespace"), and hide it from projects outside that namespace,

Now we don't have to call it a 'black-list'. I merely used that terminology get across my point.

[Draco18s]

That'd help, but I keep running into random namespace imports now and again. Ones I've never heard of before and have no idea how they're even in the project references to begin with. I'd constantly be having to add new namespaces to this file when instead of implementing a blacklist, the bug could just be fixed.

For example I copied some code with a variable named mesh which was being modified. This was a variable of type UnityEngine.Mesh

What it imported instead (keep in mind, I didn't copy the Mesh mesh = ... line as I was moving some code from one place to another to repurpose it and that line was above a huge chunk I wouldn't be using) was VisualDesignCafe.Nature.Materials.Editor.Sections;

Not that that in any way fixes the "variable not declared" issue, but now there are two Mesh classes imported. Good job assistant, you broke it. You added an unused import, you simpleton.

Investigating the spurious import, it looks like it's a nature shaders plugin of some kind. Which is to say, "it should be in the project." There is no likely reason I'd ever actually need to reference into it, but because of how Unity handles plugin dlls, they're added as references to the base project's references automatically (and you can't remove them). In theory there is a likelihood that I might want to reference into that namespace (well, other than that one looking like it's an Editor package not a Runtime package), so Unity is doing the right thing.