Add support for loading user and system-wide profile scripts

[daviwil]

PowerShellContext should support loading user and system-level profile scripts. The .NET API will expose this as a function that should be called explicitly for profiles to be loaded.

The host process will invoke profile loading by default but there should be a -NoProfile command line parameter which will disable automatic profile loading for the session.

[daviwil]

Profile locations: https://technet.microsoft.com/en-us/library/bb613488(v=vs.85).aspx

[rkeithhill]

Hmm, are you sure we should invoke a user's global profile by default? I mean if you are going to support profile loading, then the global profile just gets loaded. I think a lot of folks are probably used to dumping a bunch of configuration and module import into their profile.ps1 because they only think of powershell.exe and maybe powershell_ise.exe using it. This might open up a can of "support issues" related to profiles loading in the context of debugging in VSCode. This could also impact debug startup perf.

Whether it defaults to loading the profile or not, there would be a user preference to select the non-default behavior, right? :-)

BTW what would the host specific profile be?

Microsoft.PowershellEditorServices_profile.ps1

Also if we ever get a REPL that works when not debugging, would we use that same REPL session for debug or would we still spin up another "debug" instance of the host? Just wondering if there would be a single profile or two profiles (one for edit/design time and another for debug)?

[daviwil]

Yeah, I'm with ya on the perf impact concern. We could go with a host-specific profile to start, users can dot-source other profile files into the host-specific profile (I suppose it would be named like you suggested).

As far as whether the profile gets loaded in the debugger, it seems like the user would expect that the functions/modules they saw in their IntelliSense results should also be loaded and available when they try to debug their script. I could be wrong about that, though. Maybe I can throw out a question on Twitter tomorrow to see what people would be interested in.

No matter what, there will definitely be a preference in VS Code to turn profile loading on/off depending on what the default will be.

[rkeithhill]

If anything, you will want that preference to tell folks to turn off profile loading to see if a problem still persists. :-) Whenever I'm digging through an issue, I usually start Powershell -noprofile to eliminate all the stuff I'm tweaking and loading via my profiles.

BTW if you support profiles, can you allow a host-specific profile without also processing the user's (and machine's) global profile? I thought that was a basic fact of life with PowerShell?

[daviwil]

Hmmm... Maybe profile support should be opt-in rather than opt-out? At least that way the user knows their profile is being used.

When you implement a PowerShell host, it appears that you have to manually load all profiles if you want them all loaded. I think we'd just load the host-specific profile only if that's the behavior we want.

[rkeithhill]

I'd vote for opt-in, at least to start with. Folks who really want it will then have a way to enable it. And if there is a issue, hopefully they'll make the connection to the profile they are now running. Assuming, of course, that the profile is the cause of the issue.

[daviwil]

Cool, sounds good to me!

[rkeithhill]

OK, I think I'm just now processing the previous comment where you say that a PowerShell host can indeed process just the host-specific profile. In that case, opt-in/opt-out is simply determined by whether or not the host-specific profile exists. Since it won't exist, the user will have to create the host-specific profile and by doing so, they "opt-in". Sorry about the flip-flop there. In case it's not obvious, my main concern is automatically processing the "all hosts" profile scripts - especially the "all host / current user" $home\Documents\WindowsPowerShell\profile.ps1 file.

BTW even a host-specific profile can come in two flavors: all users and current user. Current user is the obvious one to support. Would we support the "all users" variant?

[daviwil]

Actually I hadn't connected the dots either :) The host-specific profile would indeed be opt-in because they'd have to know to create it before it gets used. We should still provide a "NoProfile" option in VS Code config in case they do want to turn it off temporarily.

For the Editor Services profile, I'd say current user only makes sense. I can't see a use case for a system-wide Editor Services profile yet. If people ask for it we can add it.

[rkeithhill]

Sounds good.

[daviwil]

Just started working on this. I think it might be better to go with a different approach for Editor Services than what's been done in the past. Instead of having an expected profile path for Editor Services, I want to provide a profilePaths setting for both the language and debug services so that the user can pick which (if any) profiles get loaded in either of those services. One cool benefit of this approach is that in VS Code, the user can have a workspace-specific profile that can load up stuff that's only relevant to that project.

In my opinion, it really only makes sense to have a standard profile path for powershell.exe because there's not an easy way to configure that. All editors have their own means of configuring settings, so it seems more flexible to allow the user to set their own profile paths, especially if they can be workspace-specific.

What do you think?