Learn about Windows PowerShell
Summary: Reload your Windows PowerShell profile without closing and reopening Windows PowerShell.
How can I reload my Windows PowerShell profile to test some changes I made—without closing and reopening Windows PowerShell?
Use the invocation operator with the automatic $profile variable:
Note Depending on how you have written your profile, you may generate a large number of errors, for example, Drive already exists or Alias already exists.
I had some problems with "& $profile" (fonction not updated), I use ". $profile" instead and it works fine.
Etienne should be right, . instead &.
@Etienne Divina @Larry I just retested this, and on my Windows 8 laptop running PowerShell 3.0 both techniques work. Keep in mind, that if you do not have a profile (use notepad $profile to check) then neither technique works.
Just tested this in powershell 4.0 on windows server 2008 R2.
It does not work.
Dot sourcing did work, however, I am not sure dot sourcing is the exact equivalent of reloading the profile.
My understanding is that dot sourcing can 'pollute' the session with conflicting variable names etc...
Would be nice if there was a technique to just reload the profile.
Dot sourcing is the better way. dot sourcing will guarantee that it is run globally. Normally variables defined in a script are not global. Dot sourcing makes them global. Functions that are defined are persisted globally.
@Matthew Copeland Dot-sourcing *is* the exact equivalent of reloading the profile. That's true not just in effect, but on a technical level, because that is how PowerShell "loads" the profile at the start of a new session: by dot-sourcing it. That's the
only thing special about the profile -- it's a script that gets automatically dot-sourced at the beginning of each session.
I think you misunderstood the warnings about dot-sourcing "polluting" the session. The difference between invoking and dot-sourcing a script is that if you invoke it, it runs in its own script scope, whereas if you dot-source it, it runs in the calling scope
(the console session or whatever script or function called it).
So, if you invoke a script, any variables and functions defined by the script are confined to the script scope (unless they're explicitly scoped otherwise), which means they're not defined in the console session or whatever parent script or function called
the script. If you dot-source the script, when it ends, any functions and variables defined in the script (at the top level) are defined in the calling scope.
Normally, when you run a script, you don't want it to leave behind functions and variables it defines, and potentially change variables in your session that have the same name as variables in the script. When you reload your profile, that's exactly what you
want; that's the *purpose* of reloading the profile. And that's exactly the problem with using "& $PROFILE". That *invokes* the profile as an ordinary script, so variables and functions defined in the profile are only available within the profile itself, and
are not added/modified in the console session.
Seriously this is the first hit on google and its wrong even after the comments point out it should be ". $profile" wasted a few minutes before reading those. Can the author please correct this for the good of the interwebs?
This may work if your profile is in your $env:userprofile\documents\windowspowershell location but not work if you use the global Windows profile.