Month: August 2012

Ensuring you get the CLR version you want when remoting in Powershell

Posted on Updated on

This is an issue I ran into recently when trying to run some of our regular Powershell scripts recently – they were the same scripts we’d always run but now we were trying to run them remotely (instead of making a person log in over RDP and run a batch file. Very high-tech, I know.) but we were running into an issue to do with the CLR version that gets loaded with your Powershell session.

We’re using our own binaries (written in C#) in our Powershell scripts, and we need v4 of the CLR loaded to get them to run. Normally v2 is what you get, but we found that you can edit the file $pshome\powershell.exe.config with the contents:

<?xml version="1.0"?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
         <supportedRuntime version="v4.0.30319"/>        
         <supportedRuntime version="v2.0.50727"/>        
    </startup>
</configuration>

This caused v4 of the CLR to be loaded, but only when you run Powershell locally. If you want to do the same when you remote into the machine, it doesn’t work.

I couldn’t find any documentation on this, but thanks to some nice people on StackOverflow I now have the answer. The configuration file contents above are still what you need, but you need to put them in another file. Two other files actually, if you’re on 64-bit. The files you need are located at c:\windows\System32\wsmprovhost.exe.config file and c:\windows\SysWOW64\wsmprovhost.exe.config.

That should be all you need!