I'm pretty new to both visual studio code and PowerShell, mostly used gitBash before. I'm just wondering if there is a way to save aliases that I set in the powershell, so I don't have to redo them everytime I restart the application.
I tried a few google searches but could not find the answer to my question.
Thank you.
S
If you're using Visual Studio Code with the PowerShell extension, you're using the PIC (PowerShell-Integrated Console) in the Visual Studio Code's integrated terminal, which has its own $PROFILE file, separate from stand-alone PowerShell installations.
You can open this $PROFILE file from the PIC as follows:
psedit $PROFILE
Any alias definitions or functions you place in there will be available in future PIC sessions by default - but only there.
Alternatively, to share definitions with a stand-alone PowerShell installation, dot-source its $PROFILE file; e.g., to dot-source:
the current user's Windows PowerShell profile, use:
. ~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
the current user's PowerShell (Core) 7+ profile, use:
. ~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
Related
What is the difference between [pwsh] and [Powershell Integreted Console] on VS Code?
I usualy use pwsh.
Today, when I installed the powershell extension and then tried to update the powershell, the Powershell Integreted Console started up and found out. What is this?ćć
pwsh[.exe] is the executable file name of PowerShell [Core] (v6+), the cross-platform edition of PowerShell built on .NET Core / .NET 5+; by contrast, powershell.exe is the executable name of the legacy Windows PowerShell edition (v5.1-), built on the Windows-only .NET Framework (v4.8-)
Windows PowerShell comes with Windows itself, whereas PowerShell [Core] must be installed on demand (on all supported platforms).[+]
VSCode (Visual Studio Code) has an integrated terminal (console) that can run any shell, such as cmd.exe, bash, or pwsh or powershell.
Shells that run in the integrated terminal by default have no special integration with the files being edited. They show by their executable file name in the dropdown list in the integrated terminal's toolbar; e.g.:
By contrast, the PowerShell Integrated Console is a special shell that comes with the PowerShell extension and offers integration with PowerShell code being edited, notably to provide linting and debugging support, among other features.
The PowerShell Integrated Console starts on demand when you first open/activate an editor with PowerShell code in a session, and it shows as follows in the integrated terminal's toolbar:
You can use the PowerShell extension's configuration to choose the specific PowerShell executable to use, which on Windows allows you to choose between running PowerShell [Core] (pwsh.exe) and Windows PowerShell (powershell.exe) in the PowerShell Integrated Console.
If a PowerShell [Core] version is installed and it is installed in a well-known location[*], it will be used by default; the fallback on
Windows is Windows PowerShell. Since PowerShell [Core] versions can be installed side by side, you can switch between different versions, if installed.
If a PowerShell [Core] version in installed in a nonstandard location and is therefore not discovered automatically, you can tell the PowerShell extension where to find it, either via the Settings GUI or via settings.json, as shown in the linked topic and the bottom section of this answer.
Whenever the active tab is a PowerShell source-code file, the status bar in the bottom-right corner shows the PowerShell version that is being used if you however over or click on the {} icon; versions >= 6 imply PowerShell [Core].
If configured, there's a separate icon that directly invokes the PowerShell session menu when clicked and which reflects the active version number - again, see the bottom section of this answer; e.g.:
[+] as of v7.0; time will tell if PowerShell [Core] will ship with future versions of Windows, and perhaps even other platforms.
[*] From the linked docs: "This feature looks at a few well-known paths on different operating systems to discover install locations of PowerShell. If you installed PowerShell to a non-typical location, it might not show up initially in the Session Menu. You can extend the session menu by adding your own custom paths." If you use one of the official installers, the PowerShell extension should find your installation.
I usually use the shortcut described here: How do I start PowerShell from Windows Explorer? to open a PS session in a specific folder. Just using powershell to open the sessions
However is no longer working, every time I write powershell on the address bar and hit enter it take me to the folder: C:\Users\MyUser\Documents\PowerShell (I'm in a Windows 10 laptop)
It seems to be related only to this shortcut as I have tried a few other things and they work. List of things I have tried/checked already below:
powershell -noprofile it work opening a PS session as expected
No, my $Profile file does not have anything to set the location of the PS Session.
powershell.exe works as expected
powershell_ise works as expected
going to File --> Open Windows Powershell works as expected
Checked my environment variables and nothing strange there either
It seems to be related to the fact that I installed PS core 6 recently. This installation introduced the folder C:\Users\MyUser\Documents\PowerShell (it's a new folder vs the ones that existed with Windows Powershell) and that's why the windows explorer now opens a folder instead of the command line.
I suppose I will need to get used to powershell.exe instead of powershell from now on.
I would like to modify the standard PowerShell profile in Windows if the Powershell opens inside VS Code integrated terminal (when you are editing e.g. python scripts in VS Code, rather than PS scripts, which opens the ISE profile in any case).
Is there some environmental variable that gets set by the integrated PowerShell? Or is there some way of opening Powershell with a particular profile, instead of the default?
Thanks
VS Code creates an environment variable named TERM_PROGRAM. You can check it for a value of vscode, something like this:
if($env:TERM_PROGRAM -eq 'vscode') {
# do some stuff...
}
If you want to check if you're running within PowerShell Integrated Console (ships with PowerShell extension) under vscode and not just any powershell console running under vscode, you can:
if ($Host.Name -eq 'Visual Studio Code Host') {
Write-Output 'PowerShell Integrated Console'
}
This is meaningful to detect because it is the only powershell console host that provided full debugger support (eg. break on exception experience) and debugger integration with vscode.
You said you're into modifying profile when running within vscode, then you should check (again with PowerShell integrated console which ships with PoweShell extension):
PS> $PROFILE.CurrentUserCurrentHost
C:\Users\username\Documents\PowerShell\Microsoft.VSCode_profile.ps1
PS> $PROFILE.AllUsersCurrentHost
C:\Program Files\PowerShell\7\Microsoft.VSCode_profile.ps1
If people are working on PowerShell code within Visual Studio Code, then why they would NOT install PowerShell extension which ships with a specific console that fully integrates with Visual Studio code and on the top of that, provides you a profile file specifically geared towards Visual Studio code?
I have Powershell files in the same folder with a number of helper functions. Unfortunately the Visual Studio Code editor does not recognize those functions when using intellisense. How do I import reference libraries and get VSCode to search those files ?
If you want the code available to intellisense you have to load it into one of two places, either the PowerShell Integrated Terminal or your editor. In your case though, if you need it loaded all the time I would simply dot source those files in the VS Code PS Profile. You can create this simply by going to the PS Integrated Terminal and using New-Item $PROFILE -ItemType File -Force and it will create a Microsoft.VSCode_profile.ps1. Anything you add in that file will get loaded into the editor and PS Integrated Terminal upload startup.
More details on the whole engine and how intellisense works in VS Code...
The reason this works is that the main engine in the PowerShell extension is the PowerShellEditorService. This is the engine that creates the host behind the PS Integrated Terminal, and the PS features you have in the editor itself (e.g intellisense, script analyzer, etc.).
You can see an example of this by adding Import-Module somemodule to a new file in VS Code that has not been loaded into the PS Terminal. It can take a few seconds but after the engine loads the module you will have intellisense for that module. Just like you will your code.
Prior to adding the commands in that editor I verified that the module was not loaded. After adding the import command and then using a command from that module the module gets loaded in the background. You can then see the module was loaded:
Iām using the Powershell extension for Visual Studio Code. I updated the profile:
C:\Users\xxxxxxxx\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
To include some functions and variables that I want to make available to other scripts. When I reference a variable from the profile within another script, it does not appear that the profile has been loaded. I suspect this because the variable value is blank when I query it from the VS Code console. If I run the same test from the standard Powershell console with an associated profile, the variable value is resolved.
Can anyone tell me what, if anything, I need to do to use a Powershell profile in VS Code while debugging?
There are several profiles. The starting point is the four locations that you can find by reading the following properties of PowerShell's built-in $profile variable.
$profile.CurrentUserAllHosts
$profile.CurrentUserCurrentHost
$profile.AllUsersCurrentHost
$profile.AllUsersAllHosts
As noted in this article by The Scripting Guy, because Windows has both Powershell and the Powershell ISE, you have at least two possible values of Current Host, so at least 6 profiles.
I've tested this in the Visual Studio Code terminal window, and it seems that the "CurrentHost" profiles are the same as you get by simply running a powershell instance. I'd assume then that Code isn't seen as a distinct host, and just runs a normal powershell.
Once you've got that far, there's another possible complication, which is that the AllUsers profiles are down in C:\Windows\System32 and hence on a 64 bit system, also mirrored in C:\Windows\SysWOW64\. So depending on whether you are using a 32 or 64 bit editor, and whether the Powershell is hosted in a 32 or 64 bit process, it is quite possible that the file you are editing has no influence on the Powershell.
Inside your debug session run: $profile. This will return the path to currently used profile file, so you can make your changes there.
Alternatively you could change the system wide profile in C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
With the just released version 0.10.0 of the VS Code PowerShell extension debugging with a previously loaded profile.ps1 being available is now implemented. Note that the interactive console and the debugger share the same PS session.
If you type $profile in the "PowerShell Integrated Console" of VSCode, you will see the path to the profile used:
C:\Users\xxx\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
Now if you type $profile in a normal terminal, you will see your "normal" profile: C:\Users\xxx\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
Now the easiest solution that did the trick for me is to create a hard link between the two files (the VSCode_profile.ps1 file didn't exist in my case):
mklink /H Microsoft.VSCode_profile.ps1 Microsoft.PowerShell_profile.ps1
Reload VSCode and you are all set!