I’ve posted a couple of articles recently regarding using later versions of the .NET Framework. Through the magic of .NET, you can just create a simple .CONFIG file to tell the relevant executable to use a later version of the framework by default. A .CONFIG file is just a very simple bit of XML as I demonstrated here, where I show how to create the XML and save it as PowerShell.Exe.CONFIG. This worked fine to enable the PowerShell console to use later versions of the framework. And I showed some of those results in a separate post here.
To enable this work work with PowerShell Plus, I just went and found the executable for PowerShell Plus, created the relevant .CONFIG file (PowerShellPlus.Exe.CONFIG). Now PowerShell Plus brings up .NET 4 too! Yeah! Or so I thought.
After posting these articles I saw on Twitter that @qa_warrior was having trouble doing this remotely. The upshot of his problem was that even though he’d configured PowerShell to use .NET 4.0 on both client and server, when he remoted, his remote session was based on 2.0. It turns out that this too was simple to fix – if you understand how PowerShell remoting is implemented on the remote host
When you create a new PSSession with a remote server, what you are doing is instantiating a PowerShell runspace and sending it commands to execute (and returning the results, albeit serialised). In order for the remote machine to create (and later use) the runspace, Windows needs to house that runspace inside a process. Powershell 2.0 creates that runspace inside an executable wsmprovhost.exe. You can see this in action here:
In this screenshot, I created two remote sessions (admittedly to my self – but ‘remote’ nonetheless). You can see the two occurrences of wsmprovhost.exe and the two remote sessions. After removing these remote session, you can see that there are no occurrences of either wsmprovhost or the remote sessions. Then after you create a new PSSession, you can see the new session and the new occurrence of wsmprovhost.