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"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
"@$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.
