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?

[rkeithhill]

I like the idea of a workspace specific profile. Since it is profilePath**s** would this be an array of strings i.e. paths to process in the order specified?

[daviwil]

Yep! Exactly. I think it gives more flexibility that way.

[daviwil]

Hmmm, OK, seems like having a list of profiles won't work since doesn't jive with how the $profile object is supposed to work. Now I'm thinking that maybe it's enough to just have a single customizable profile path which gets used as the value for $profile and $profile.CurrentUserCurrentHost. It seems like we can use any absolute path in the system for this profile path.

There's still the question about what should be given for the rest of the profile properties. Here are some ideas:

• $profile.AllUsersAllHosts and $profile.CurrentUserAllHosts - these normally resolve to profile.ps1 in their respective folders. We could either make these fully configurable or give a single boolean setting like includeAllHostsProfile which will cause these profiles to be used from their default locations.
• $profile.AllUsersCurrentHost - this seems less useful in the case of the editor host. Maybe we can always just leave this one blank until someone asks for it?

What do you think?

[rkeithhill]

I would try to work within the confines of how PowerShell users expect $profile to behave and not do anything unusual here. For instance, when running a script in the debugger I would expect $profile.CurrentUserCurrentHost to return a string like <user-home>\Documents\WindowsPowerShell\Microsoft.PowerShellEditorServices_profile.ps1. If we allowed a user to set this value to some arbitrary path - well, that would be a bit weird. In fact, I'd expect all four fields of $profile to be filled out.

That said, if we start supporting profiles, I think we should add a setting to disable profile loading equivalent to powershell.exe's -NoProfile parameter. I'm pretty sure my CurrentUserAllHosts profile.ps1 file would probably bust things.

Now that covers the case of a "user" having VSCode setup a particular way for editing PowerShell in all VSCode instances. But what if that user wants to share that initialization/profile setup with others on his team. In that case, they will want to check that in under the workspaceRoot folder. This is where the standard profile locations fall apart. This case, I believe, is handled better with an initialization script. In fact, I think the Runspace constructor takes an initialization script (or perhaps it is passed in via an options object).

In this scenario, you could have a powershell.editorInitializationScript setting that took a path (typically workspace root relative). One question though, is this for the editor only or for both editor and debug host? I think I would only load this for the editor otherwise you make it too easy for folks to write/debug scripts that don't run outside of VSCode. :-) For instance, it is entirely likely that a user will have their script load the snapin so that it will work outside of VSCode or on another machine. So having the same initialization script that runs for the editor (to save them the hassle of selecting the Add-PSSnapin line and pressing F8) could cause a problem when the script is run in the PowerShell debugger. Particularly if their script doesn't deal with any errors you might get when attempting to add the same snapin again.

You know, these two approaches could be done orthogonally. I think the editorInitializationScript approach makes sense to do first. This works best for the "per-workspace" editor initialization case. And it should be simple. Later, if we ever get a true REPL in VSCode, that is where having profile support really makes sense IMO.

[daviwil]

That's a good way to break it down. Having a separate init script option would definitely be handy for any extra workspace-specific runspace configuration for editing purposes. The user could also use it for loading project-specific command extensions with the new extensibility model.

Since I've just about got profiles support finished now, I'll simplify it so that we only do things in the expected way. A NoProfile option is definitely a must, and I agree that we wouldn't want profiles being loaded up in the debugger.

One last question: should we at least allow the editor to dictate what the X is in X_profile.ps1 so that each editor can have a unique profile? For instance, PoshTools currently has its own PoshTools_profile.ps1. Seems like it'd be nice if we could allow that once it gets moved over to Editor Services. For VS Code we could have something like VSCode_profile.ps1 or a better name. Could also use this in the ISE. Do you see any value in editor-specific profiles?

[rkeithhill]

One last question: should we at least allow the editor to dictate what the X is in X_profile.ps1

Must stop thinking of it as a vscode-only editor services. :-) So yeah, it would make more sense for the file to be called something like ms-vscode_profile.ps1 or ms-vscode.PowerShell_profile.ps1. The first one is probably unique enough.

[daviwil]

Awesome! I'll send a PR for this stuff tomorrow.

[KirkMunro]

I'm glad you're adhering to the existing profile handling standard. Make sure you respect the profile load order the way it is done in PowerShell as well, please.

[daviwil]

Yep, I can see the order that the ISE uses:

1. AllUsersAllHosts
2. AllUsersCurrentHost
3. CurrentUserAllHosts
4. CurrentUserCurrentHost

I've used the same loading order, skipping the ones that don't exist.