**Updated August 23rd 2016 as there was a change between 6.0.0.8 & 6.0.0.9 to PSModulePath that I had missed – I will be blogging about this in more detail in a future post but for now check the updated section at the bottom of this post! **
If your like me and you want to test out PowerShell Core on you Windows machines as well as other *nix machines then you may get caught out with this like I did in the upgrade from 6.0.0.8 to 6.0.0.9.
You can grab the MSI installer for 6.0.0.9 at https://github.com/PowerShell/PowerShell/releases/tag/v6.0.0-alpha.9 however do note that there are no Windows 7 or Windows 8 installers due to the requirements for WMF 4 to have been installed prior to WMF 5 as noted in this issue https://github.com/PowerShell/PowerShell/issues/1931 which links to this issue https://github.com/PowerShell/PowerShell/issues/1705
So lets get into the Side by Side stuff 
Once you’ve installed the MSI install you can run PowerShell 6.0.0.x alongside the Installed Version on your machine like so
This is because PowerShell 6x installs in the following Location C:\Program Files\PowerShell\ and as you can see below I have installed 6.0.0.8 & 6.0.0.9 on my machine.
This also means that if we look in our Start Menu you can see the following new options
Note This will not change your default version of PowerShell from the one that is at C:\Windows\System32\WindowsPowerShell\v1.0\ so if your running Windows10 on the Insider Fast ring like me then it will run 5.1.1405.1000
To run one of these alpha versions you have to explicitly do so from the Start menu (or a desktop link if you create one) so you can be sure that this will not cause your any issues with day to day PowerShell use.
Hopefully that clears up any potential confusion!
In 6.0.0.8 the $profile Variable referenced the Windows PowerShell Documents location as can be seen below
Whereas in 6.0.0.9 we have a new location as shown below
So when we load 6.0.0.9 we wont get our profile to load as it doesn’t exist.
So that we can get our current profile to load in 6.0.0.9 we can do what we would normally do and just use New-Item like I’ve shown below
This seems only to have been needed in 6.0.0.8 & not 6.0.0.9 – as the default values in 6.0.0.9 for the PSModulePath are not what we have set in the ENV Variable and I’m not sure how this works but will dig in and post about this at a later date!.
Then next time we load 6.0.0.9 we will have a working profile but the issue is that this will now enable loading of all the modules that we have in our PSModulePath environmental variable.
However we can get round this by 1 simple line in our Profile (split into multiple for ease of reading)
If ($PSVersionTable.PSEdition -ne ‘Desktop’)
{ if ($IsWindows -eq $true)
{ $version = $host.UI.RawUI.WindowTitle.Split(’_’)[1] ;
$env:PSModulePath = “C:\Program Files\PowerShell$version\Modules” ;
Write-Output ‘Removed all but the shipped Core modules’
}
}
This is a Windows only forwards compatible inclusion in your profile & will only affect the local session of PowerShell that is running.
So you can be sure that this will work across your Windows Machines however ideally we will get some amendments to PSVersionTable as noted in https://github.com/PowerShell/PowerShell/issues/1997 & https://github.com/PowerShell/PowerShell/issues/1936 to be able to tell the OS easier and more dynamically.
The $IsWindows variable is only available in PSCore along with $IsOSX , $IsLinux & $IsCoreCLR so you cannot currently use them in the Full Version of PowerShell and currently I don’t think that you can build the full version of PowerShell from the Repository to a 6x version. However this may change in future.
So you can actually with 6.0.0.9 and above ignore the above section completely and comment that out of your profile (or delete it)
This is also a good example of the rate of change between the different alpha versions although I’ve checked the commit notes and cant see this change mentioned in a concise and easy to understand manner so I will feed this back to them to see if release notes can be improved in future.