« Real-World Metro: GitHub for Windows | Main | Discovered 2012-05-13 »

The easy way to run Powershell 2.0 using .NET Framework 4.0  

If you've been exploring creating your own modules and cmdlets with Visual Studio, you've likely stumbled onto the following problem: you are unable to load your module using the import-module command because of an error stating that “This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.”


The reason is simple enough. When PowerShell 2.0 starts it is using the old .NET Framework's CLR (which begins which is version 2.) so it will be able to load it modules compiled against .Net Framework 3.5 (which continues to use the version 2 CLR) but not .Net Framework 4.0 (which uses the version 3.0 CLR). This is perhaps a little surprising because Windows 7 comes with .NET Framework 4.0 installed.

You can see exactly what versions Powershell is using by examining the value of $PSVersionTable


Notice the value or CLRVersion begins with a "2".

In any case, this is a common occurrence with a straightforward solution. You can force PowerShell and PowerShell ISE to start using the .NET Framework 4.0 as documented in this StackOverflow question. The procedure involves creating two small XML files and placing them in the appropriate place.

Being lazy, of course, we hate manual steps, so here is a small PowerShell script that will automatically create and place the necessary files. Be aware that the script as shown below will overwrite existing .config files.

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

$config_text| Out-File $pshome\powershell.exe.config
$config_text| Out-File $pshome\powershell_ise.exe.config

Start PowerShell as an Administrator an then run the script.

Now restart PowerShell and examine the value of $PSVersionTable.


Notice the value or CLRVersion now begins with a "4".

And now your .NET 4.0 module will load correctly.




PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (4)

Thank you!

I came across this issue while trying to import the Veeam Backup 6.5 .dll module.

your script did the trick!

October 30, 2012 | Unregistered CommenterLéon

The correct way to do this (the MS recommended way):

Set Environment Variable 'COMPLUS_ApplicationMigrationRuntimeActivationConfigPath' to point to a path we will call P, this is much much cleaner than placing files in a system directory (FYI, the $pshome variable points to the wrong folder on Windows 64bit, the file should have gone to 'C:\Windows\SysWOW64\WindowsPowerShell', not System32 as this will give errors.)

Create your 'powershell.exe.activation_config' in this path P

from: http://msdn.microsoft.com/en-us/library/ff361644(v=vs.100).aspx

April 12, 2013 | Unregistered CommenterJorbes

I've ran this script as Administrator but still receiving this error:
Access to the path 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe.config' is denied.

running on Windows 8

June 28, 2013 | Unregistered CommenterSergiu

@Sergiu - Thanks for informing me. I'll look into it - but I am curious why you you need to do this on Windows 8 - PowerShell in Windows is already using the latest .NET Framework.

One question: When you have an elevated command prompt - either CMD.EXE or PowerShell - are you able to copy a file into that folder with the copy command?

June 28, 2013 | Registered Commentersaveenr

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>