Add support for loading host profile scripts

[daviwil]

This change adds support for loading both host-agnostic and host-specific
profile scripts for the current user and all users depending on which of
those scripts are available on the system. Profile loading behavior is
opt-in and not enabled by default. Regardless of whether profiles get
loaded, a $profile variable is inserted into the PowerShellContext's
runspace upon initialization.

Resolves #111.

---

This change is

[daviwil]

Is this the right setting name for what the user would specify in VS Code? I used the positive form rather than the negative form (noProfile) since profile loading is never performed by default.

[rkeithhill]

Seems reasonable to me especially if we need a positive form of the setting.

[daviwil]

This PR isn't fully done yet, I still need to do a little cleanup, commenting, and name tweaking. Would appreciate some feedback on the design to make sure I didn't miss anything. I should be replicating the behavior of powershell.exe and powershell_ise.exe exactly with this implementation.

[KirkMunro]

Just curious, why differ by not loading profiles by default? Every PowerShell editor since 2006 has loaded profiles by default, just as PowerShell does.

[daviwil]

I suppose the main concern is that if profiles are all of a sudden being loaded in VS Code by default, it could break existing users (maybe they do something that we don't support yet). When used as an API for other purposes, I'd expect Editor Services to only load profiles when asked for. I can see your point though, there's already the established concept of NoProfile which is pervasive in PowerShell tools.

Keith, what do you think? Should we load profiles for the language server by default?

[daviwil]

Just tweeted a question about this to get some more feedback.

[KirkMunro]

If a profile contains things that are not host-specific and yet are not supported in your editor, those things can be moved into an if statement that checks the host name. People using VS Code while PowerShell-support is still a work in progress should be technical enough to manage the transition through the process.

[rkeithhill]

I'm OK with that as long as there is a way to turn it off like ISE's -NoProfile parameter. And if it is on by default, then naming it something like disableProfileLoading makes more sense.

I can update some of my profile.ps1 files to make this work for me. Some I have updated to only load PSReadline in the "ConsoleHost" but I have some other machines I need to make that change on.

[daviwil]

Ok, after getting some good feedback on Twitter, here's what I think I'll do. In the beginning I'll have the loadProfile setting defaulted to false in VS Code so that it's business as usual for everyone after the 0.6.0 update. I'll recommend that people try turning it on to see how it goes for them and then fix any issues that come up. When VS Code finally gets a REPL, I'll change the setting true by default since profiles would generally be more helpful for the interactive console. How does that sound?

Regardless of whether it's on or off by default, I think I like the strategy of having boolean parameters mean 'true' for the positive case rather than the negative case so there's no cognitive dissonance. However, I like enableProfileLoading better than loadProfile so I think I'll use that name instead.

[daviwil]

One other thing I realized is that I'll also need to set PSHost.Name based on the editor so that editor-specific profile logic can be used. The host exe will need to take another parameter for hostName so that it can be set when the host is launched. Thinking about having VS Code set it to "Microsoft Visual Studio Code Host" unless you have objections.

[rkeithhill]

I think that host name is fine. Just make sure the profile filename does not have spaces in it. For that host name, I'd expect a profile name like Microsoft.VisualStudioCode_profile.ps1. That presumes no other Microsoft group will write a PowerShell host for VSCode that loads a profile (or if they do they'll need to pick a more unique name).

If you wanted to shorten the $host.Name response you could drop Microsoft from the name. I see that ISE returns Windows PowerShell ISE Host yet the profile name it uses is Microsoft.PowerShellISE_profile.ps1.

[daviwil]

Technically $host.Name and the name used for the profile filename are two different strings. I was thinking of using Microsoft.VSCode_profile.ps1 for the profile filename. I'll use "Visual Studio Code Host" for VS Code's $host.Name instead since "Microsoft" isn't used in the other hosts.

[KirkMunro]

This approach makes sense to me. My suggestion was thinking more about when you have a REPL anyway.

[rkeithhill]

👍

[daviwil]

Awesome, thanks for all the ideas and help!

[daviwil]

Alright, I think the quality on this is pretty good now. One last-minute change I made was to allow the "host application" (the editor) to pass their version through so that it shows up in $host.Version. Since we're passing through the name of the editor, it makes sense to also pass the version of the editor (or in the case of VS Code, the version of the PowerShell extension). This would be the first step in allowing an extension author to know what capabilities are available for the session they're running in.

The new extensibility model will introduce a $psEditor object (same concept as $psISE) which will contain the actual version of Editor Services so scripts running in an editor session will be able to tell both the editor version and the version of Editor Servicies that's being used.

How does that sound?

[KirkMunro]

Glad you're setting up the version the right way as well. Some editors in the past have simply reported the PS version in that property, but modules that extend the editor will need the editor version.

[daviwil]

Thanks! Glad to hear that was the right thing to do. If you can think of anything else that would be the "right way" compared to other PowerShell hosts, definitely let me know.