Better intellisense for .NET?

[Rhywun]

Issue Type: Feature Request

It would be very helpful to show popup documentation for .NET objects and members while coding in PowerShell, similar to what is already present for cmdlets. Is it possible with this extension or some other extension? The code completion for .NET objects works great but it would be nice to show the doc comments in the drowdowns and tooltips too.

Extension version: 1.7.0
VS Code version: Code 1.24.0 (6a6e02cef0f2122ee1469765b704faf5d0e0d859, 2018-06-06T17:30:30.113Z)
OS version: Darwin x64 16.7.0

[TylerLeonhardt]

I like this idea - It would be nice to have something like this similar to what PSReadLine offers:

[rjmholt]

This should be possible by using PowerShell's API for getting PSMethod overload definitions.

e.g.

[string]::Combine.OverloadDefinitions

[SeeminglyScience]

This should be possible by using PowerShell's API for getting PSMethod overload definitions.
e.g.

[string]::Combine.OverloadDefinitions

We do already show that. The harder part is showing hints for the current parameter. Without type inference it's hard to tell what overload to show. Also the OverloadDefinitions property is just an array of strings, so we'd have to do some string manipulation to get specific parameters out of it (not saying that's impossible, just unfortunate)

In ESCS I ripped the type/member inference code from PowerShell, replacing internal API's with public ones. I'm testing it out there, if it goes well then porting it into PSES would make this a lot easier.

[rjmholt]

Also the OverloadDefinitions property is just an array of strings

Wow

[Castillu84]

"[System." is not recognized by Visual Studio Code Intellisence, nevertheless in PowerShell ISE is well recognized. In general, all the .net code in brackets [],is not detected in VSC.

[SeeminglyScience]

@Castillu84 Can you double check that the language mode on the document is set to PowerShell?

Here's the results I get

[Castillu84]

Hi Patrick, I began to use Visual Studio Code few days ago. I didn't know about language mode in the document, but there's something strange anyway.The powerShell language intellisence don't work when the console is closed. In my case, this happend me. I show'll you with some screen shots: 1. I configure PowerShell as default language:  2. I check that powershell language is configured in the right below editor, then I close the powerShell console and try to write some code when the console is off and after when console is on. This is the result.     Anyway It has easy solution. Don't close the console. First time it can be confused, but when it's known it isn't a problem. :)

[Castillu84]

Hi again,

I found it behaivor is by design. The PowerShell module need to have the integrated console run.

Best Regards,

[SydneyhSmith]

Closing this issue as resolved

[rjmholt]

@SydneyhSmith going to reopen this one. Essentially, PSReadLine does parameter intellisense pretty well but it does something beyond PowerShell. This means it's possible, but we need to do extra work. It's not planned for us to work on, but is on the list of enhancements to make if anyone wants to give it a go.

[NWarila]

Yeah as someone who has been using PowerShell ISE for years and only recently started to try and migrate VSCode there seems to be a number of growing pains that I feel could be avoided with some minor changes. Instead of requiring console to be open, would it make more sense to have a system console process that VSCode could open/manage to operate the intelligence. This would have the added benefit of per-session console caching. Not sure the feasibility of this, just a script kiddy but figured I would give my 2c.

[JustinGrote]

@NWarila the problem is due to the dynamic nature of Powershell, add-type, etc. doing it in a separate console can lead to inconsistent results unlike languages like C# where the types are all defined either up-front or in the documents, but aren't defined in the PS console dynamically at runtime or after module import. It was also done this way to be as close to the ISE as possible to help ease transition.

We can look at some of the more static types to be processed in a separate runspace but that will probably take some significant engineering.

[NWarila]

@JustinGrote, wouldn't it be possible to hook 2 consoles into the VSCode environment, one the user interacts with and one that is more or less "read only" per say that is used by the VSCode engine. Not arguing, just trying to better understand possibilities.

I understand it would be a performance hit to VSCode but I feel it would be quite minor considering the more consistent functionality gained. It would also help with issues where ctrl-c in the terminal causes the terminal to close abruptly, which seems semi-frequent occurence.

[JustinGrote]

@JustinGrote, wouldn't it be possible to hook 2 consoles into the VSCode environment, one the user interacts with and one that is more or less "read only" per say that is used by the VSCode engine. Not arguing, just trying to better understand possibilities.

I understand it would be a performance hit to VSCode but I feel it would be quite minor considering the more consistent functionality gained. It would also help with issues where ctrl-c in the terminal causes the terminal to close abruptly, which seems semi-frequent occurence.

Say you add-type in the first console and load an assembly. How is the second console supposed to know about it in order to intellisense it?

It's just too fragile, PowerShell is neither a strongly typed nor statically typed language, most of the constructs come from runtime, therefore the runtime has to supply it. Anything else would be a monumental amount of work unfortunately.

[shackcrack007]

is there any news about this issue?
see my full question here https://stackoverflow.com/questions/77895038/in-vscode-how-to-get-intellisense-working-for-powershell

[JustinGrote]

@shackcrack007 See #1356 (comment)

As a general rule we try not to put any magic intelligence into the extension/PSES if we can get away with it (e.g. string parsing of these overload definitions) because it is fragile and prone to breakage in obscure ways, and the proper solution would be to get a method exposed in PowerShell proper that would provide a typed version of this information, if we had that then implementing this becomes a lot easier.