I think this is related to the powershell extension. I installed vs-code last week, and then late last week was an update. Today when I fired up vscode and started working I noticed the fan starting spinning up and stayed up.

After I closed vscode down that went away. In defense of vscode here I only had 6 files open and only editing one, and honestly it was about an hour before I actually started editing a file, but I noticed the fan spin up before then. I thought perhaps I was getting an update via windows updates so I didn't think anything about it, until after a while I realized the fan never stopped.

Right now when the language service crashes the user has no idea that it has happened. They just see that features have generally stopped working. There needs to be some kind of indication that an error occurred so that the user can check the log file and potentially send it in for analysis.

I (reluctantly) would like to open a discussion regarding which bracing style to use for snippets. Right now, the latest snippets file uses Allman style bracing e.g.:

function foo
{
    ...
}

But the bulk of the PowerShell code I've seen in the wild uses K&R style e.g.:

function foo {
    ...
}

I know there are details of bracing style the community at large doesn't agree upon like whether or not to use cuddled else but I do believe K&R is fairly well accepted at the "top level".

Would anyone object strenuously if I changed the snippets to use K&R?

jsut installed vs code + powershell extension and restarted vs code.
Now create a new .ps1 file, typing get- then [ctr]>+[space] I'm getting No suggestion message.
Go to definition don't seems to work either...
Any thoughts ?

This is because the powershell extension does not contribute an "initialConfiguration".
Examples can be found here

I can also do a PR, but your probably know better what should be the default launch configuraiton

Some analysis warnings are really annoying. Can I suppress the warnings?
For example, it there's a issue about the Function Name, it will put a green line under all the content in that function.

I used the launch.json sample from c:\Users\<yourusername>\.vscode\extensions\daviwil.PowerShell\examples:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "PowerShell",
            "type": "PowerShell",
            "program": "DebugTest.ps1"
        }
    ] 
}

For type Visual Studio Code shows a warning: Value is not an accepted value. Valid values: ["node"].

There is also another warning Missing property "request" in launch.json

VS Code debug adapter configurations have now been updated to accept an args array:

microsoft/vscode#1199

This can be used to replace the current .cmd file hack we use to pass the /debugAdapter parameter to the PowerShell Editor Services host process.

When a PowerShell File is opened through a WebDav Path (e.g SharePoint Library access through Windows Explorer) the extension crashes with the following error in the EditorServices.log:

FATAL UNHANDLED EXCEPTION:

System.UriFormatException: Invalid URI: The hostname could not be parsed.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at System.Uri..ctor(String uriString)
   at Microsoft.PowerShell.EditorServices.Workspace.ResolveFilePath(String filePath)
   at Microsoft.PowerShell.EditorServices.Workspace.GetFileBuffer(String filePath, String initialBuffer)
   at Microsoft.PowerShell.EditorServices.Host.LanguageServer.HandleDidOpenTextDocumentNotification(DidOpenTextDocumentNotification openParams, EditorSession editorSession, EventContext eventContext)
   at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.MessageDispatcher`1.<>c__DisplayClass4`1.<AddEventHandler>b__3(Message eventMessage, TSession session, MessageWriter messageWriter)
   at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.MessageDispatcher`1.<DispatchMessage>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PowerShell.EditorServices.Host.LanguageServer.<ProcessMessage>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PowerShell.EditorServices.Host.MessageLoop.<ListenForMessages>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PowerShell.EditorServices.Host.MessageLoop.<StartMessageLoop>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Nito.AsyncEx.AsyncContext.<>c__DisplayClass3.<Run>b__1(Task t)
   at System.Threading.Tasks.ContinuationTaskFromTask.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Nito.AsyncEx.AsyncContext.Run(Func`1 action)
   at Microsoft.PowerShell.EditorServices.Host.MessageLoop.Start()
   at Microsoft.PowerShell.EditorServices.Host.Program.Main(String[] args)

Side-loaded the v0.2.0 release for testing and experimentation today. Have noticed that the F8 functionality ceases to work and the output window for PowerShell is unavailable.

It would be nice to have a readme for all configurable settings related to PowerShell in VS Code, such as
"PowerShell.editorServicesHostPath"
"PowerShell.waitForDebugger"
"PowerShell.enableLogging"

If you run a line with Read-Host you get "Read-Host : The method or operation is not implemented."

This requires an implementation of the DocumentSymbolProvider and WorkspaceSymbolProvider interfaces. Relevant code will need to be added to PowerShell Editor Services to support this behavior.

I open powershell command console and type Code then hit enter (also tried with Code . ) and the extension doesn't work. if I use the Code shortcut from my task bar it works fine. Though doing ">ext show" says the extension is loaded, it's not working. I type "get-pro" and ctrl+space and I get completion items in the taskbar launched code, but not in the powershell command line launched code.

From microsoft/vscode#714
From @MakwaWes
CC @daviwil

Hi,

Problem
Some PowerShell modules aren't automatically loaded by 'Microsoft.PowerShell.EditorServices.Host.exe'.
The following path isn't included : '**C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules**'
although it actually reads the x64 counterpart ('C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules').

Thanks !

The whole enumeration / enum keyword feels like it's not implemented to have a support for it. Doesn't highlight the keyword or it's content and doesn't offer any snippets.

By default 'ON' but would be nice to be able to turned it 'OFF'.

When writing LCM configuration with Code I found that it adds an extra character at the beginning of the code when using the intelisense. Example seen below, if you use intelisense to autocomplete the settings of the LCM it leaves the first character you typed to search for completion.

[DscLocalConfigurationManager()]
Configuration LCMPull {
    Node Localhost {
        Settings {
            aActionAfterReboot = 'ContinueConfiguration'


        }
    }
}

On Windows 7 I cannot seem to get the debugger to work.

Extension is not useful for real-world powershell scripts, if in Debug mode I cannot step into line where call to nuget.exe with parameters.

Now I receive an NotImplemented exception in this case.

When tabbing for autocomplete on a property from intellisense, either the period is removed or the entire object + property is replaced with the property name.

If you issue a command line "gci", the terminal output is word wrapped to a very narrow window, instead of occupying the full space available. If you resize the window, the output doesn't adjust.

I have tried several combinations of "args": [] and none of them produce a $args in the debugger. Should the "args" parameter for a configuration work? Looking through the source but not finding anything yet.
{
"version": "0.1.0",
"configurations": [
{
"name": "PowerShell",
"type": "PowerShell",
"program": "PowerShell Scripts/output.ps1",
"args": ["Verbose:$true"],
"request": "launch"
}
]
}

The debugger launches fine, but attempts using "-Verbose", "-Verbose:$true", or "/Verbose:$true" do not get passed to $args. The "output.ps1" file is very simple:

Write-Output $args
Get-Process
Write-Verbose -Message "Debugging PS in VSCode!"

When a function is scoped (e.g. function Global:DoSomething(){}), code analysis (warning) is triggered with 'Reserved character in name'.

I guess I've gotten used to C# snippets that are "functional/productive". I find snippets like this in the PowerShell extension to be an awkward hybrid:

switch ($x)
{
    'value1' {  }
    {$_ -in 'A','B','C'} {}
    'value3' {}
    Default {}
}

Seriously, what are the odds that I'll have value1 as a case or a second or third case as shown above. I believe these were written to show how to use a feature i.e. they are teaching. That is admirable but as soon as the user learns the features of switch, this snippet becomes cumbersome because now it is a toss-up WRT how much code they have to "delete" to make the snippet conform to their intent versus how much they would have typed in the first place without using the snippet.

I propose that at the very least the "common" language features lean more towards being productivity snippets and not "teaching" snippets. I recommend changing the switch statement snippet to something like:

switch ($variable) {
    condition { action; break }
    Default {}
}

Where the cursor is put on a condtion placeholder second after $variable and then the action placeholder would be third.

BTW here are a few more examples of what I'm talking about:

try
{
    1/0
}
catch [DivideByZeroException]
{
    Write-Host "Divide by zero exception"
}
catch [System.Net.WebException],[System.Exception]
{
    Write-Host "Other exception"
}
finally
{
    Write-Host "cleaning up ..."
}

for ($i = 1; $i -lt 99; $i++)
{

}

Everybody who uses the try/catch/finally snippet is going to have to remove the DivideByZeroException and likely have to change the last catch to use an exception they want to catch (or not specify one at all). I believe there should a single exception there and it should be a placeholder. Likewise everybody is going to have to replace 99 in the for snippet. Might as well make it a placeholder.

I installed VS Code from Chocolatey and updated with the Powershell language extension then restarted Code. when I try to enter debugging I am presented with this message:

Shouldn't this be included with the Powershell extension? If not, how should this be configured? Thanks!

Not sure yet whether this is a configuration issue or something else. I don't see the signature help request get called at all, so maybe something changed after 0.9.2 where it isn't getting triggered the same way anymore.

I had multiple windows open. The editor I updated the Powershell Extension in only had xml files loaded in the open window and the working files section. I had a second window open with a .bat file in the editor and an assortment of files in the working files section. A few being ps1 files. I am unsure if the Powershell editor services will still be loaded/locked if there are files in the working files section or not.

I updated the extension and it reloaded the current editor with the xml files. At this point the extension plugin stopped working and could no longer load extensions. I then relaunched the editor and I started getting errors where the extensions plugin was crashing. A second restart cleared this up, but the Powershell plugin was left in a broken state. What was left in the directory was the following:

.vsixmanifest
bin --> Microsoft.PowerShell.EditorServices.dll
--> Microsoft.PowerShell.EditorServices.Host.DebugAdapter.cmd
--> Microsoft.PowerShell.EditorServices.Host.exe
--> Microsoft.PowerShell.EditorServices.Protocol.dll

I am assuming the second open editor kept the Editor Services locked and broke the update. @daviwil we talked about the log maybe being the culprit, but I did not have the editor services log still loaded in cmtrace, so that was not what had the lock.

Should VS Code require a full restart before fully updating it's plugins instead of just the currently open editor? If we compare VSCode to Atom, I believe Atom requires a complete restart. When you use the Restart prompt presented by a extension install or update, it only restarts the current window and not all windows. I am unsure if this would be something this plugin should fix or VS Code itself.

I can try to find some more logs if you need, I didn't see any at first glance since I had restarted the editor so many times. I am also going to try to reproduce this in a few different ways later when i have more time.

Adam Driscoll's new WebSocket channel in PowerShell Editor Services makes it possible to connect to a remote Editor Services host. We should figure out how to make it possible to connect to such a server via the VS Code extension (including having settings to configure the connection).

Tab completion doesn't work for anything (enum, validate set, parameters). It should work like in ISE so you could tab complete your enum sets and validate sets as arguments, parameters for functions and commands.

It's wrong far more often than it's right on my code, and the annoyance of the warnings is really starting to get to me.

Scenario

I'm using a Macbook Pro, running Mac OS X El Capitan 10.11.1. I'm authoring PowerShell scripts in Visual Studio Code, but for obvious reasons, I don't have Intellisense capabilities, or line-by-line debugging support.

Proposed Solutions

A couple of potential options for solving this scenario are:

1. Add support for PowerShell to execute natively on non-Windows operating systems (Mac OS X)
2. Support remote debugging through PowerShell Remoting (PSSession) / Windows Remote Management (WinRM), via the Visual Studio Code Debug Adapter.

Cheers,
Trevor Sullivan
Microsoft MVP: PowerShell
http://trevorsullivan.net
http://twitter.com/pcgeek86

/cc @daviwil

when using code this like this

Get-Process | Where-Object -FilterScript {
    # do things
}

the Where-Object does not highlight properly. the 'Where' goes purple and the '-Object' goes white (default theme).

not a huge deal, just an FYI. Thanks!

Visual Studio Code uses Yeoman for their "File -> New Project" experience, so we need to produce a Yeoman template that can generate a new PowerShell module project. Potentially other project types as well (DSC resource, etc?).

With the December 2015 update of VS Code a new deactivate() method has been introduced to allow extension deactivation. This will allow us to shut down the language server when the extension needs to close, improving the experience around extension upgrades.

More info: microsoft/vscode#537

As of the following pull request, PowerShell Editor Services now has both x86 and x64 hosts:

PowerShell/PowerShellEditorServices#92

We should add a setting in the VS Code extension so that the user can select their desired host bitness.

Both the README.md and the contents of the VSCode Marketplace page for this extension (https://marketplace.visualstudio.com/items/ms-vscode.PowerShell) should include a placeholder for the version number e.g. c:\Users\<yourusername>\.vscode\extensions\ms-vscode.PowerShell-<ext_version>\examples.

With 2 fresh installations on 2 seperate Windows 7 installations, Intellisense appears to be broken, with no suggestions offered for Cmdlets or variable names.

Both were installed via the built in extension installer

I've upgraded to VS Code 0.10.1 and installed the extension per the instructions. Opening the examples folder as suggested. Right-clicking on the "Do-Work 5000" entry (as shown in the gif) in the DebugTest.ps1 file only shows the following choices in the pop-up window: Change All Occurrences | Copy | Cut | Paste

A couple of restarts and still no luck. Thoughts?

For talking with Exchange Online I need to enter credentials.

My favorite way to get them is this:
$LiveCred = Get-Credential

But in VS Code on windows opens to let me enter them.

The language and debugging services are not supported on Linux and Mac OS X so a warning message should be displayed when the extension is activated on either of those platforms. Syntax highlighting and snippets support will still be available on those platforms, however.

Is there any intention to package 3.1 as a .zip release for sideloading? My work environment is disconnected - without a way to mirror the packages for sideloading, I can't distribute to my team. I would vastly prefer to grab the package from here for this purpose.

When running the debugger, debug console output never appears. The DebugTest.ps1 script will run, variables can be watched, breakpoints work, etc - but no output will ever appear in the debug console. We've attempted multiple script and launch.json configurations with no success. The latest attempt was made with:

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "PowerShell",
            "type": "PowerShell",
            "request": "launch",
            "program": "DebugTest.ps1"
        }
    ]
}

We've tried this on a couple different installs on two different machines.

DebugAdapter.txt
EditorServices.txt

When using the command palette to edit preferences for snippets, powershell shows up twice on the list. There is only one powershell.json file in %AppData%\Code\User\Snippets.