Here's an error message I'm looking forward to seeing a lot of:
Import-Module : Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
This came from a recently asked question in my Ask the Experts forum, and I wanted to share it here because I expect it'll come up a lot in the future. Don't spend time looking for how to provide the "additional configuration information" the error message refers to - you can't. That information would need to be provided by the module's developer, not by you as a parameter to the command.
The actual problem? This admin tried to load a PowerShell module that was written for PowerShell v2. More specifically, the module was compiled against .NET Framework v2 (which is what PowerShell v2 is built against; Framework v3.51 actually includes all of v2, so that'll work as well). The problem is that he tried to load the module in PowerShell v3, which is built against .NET Framework v4 - so the module couldn't load. This module actually is a "mixed mode" module, as the error message implies, meaning it consists of both managed (.NET Framework) and non-managed (native) code; those are a bit pickier to deal with. Had the module been written purely in .NET, it would have been fine in PowerShell v3... but since this one also contained unmanaged code, there's a problem. The PowerShell team tells me they expect this to be a rare situation - less than 10% of current modules - so maybe this won't be such a frequent error. I'm told to expect it more in the Windows OS modules (BITS was given as an example) than in others.
Here's a quick summary of the versioning:
- PowerShell v2 = .NET Framework v2/v3.51
- PowerShell v3 = .NET Framework v4
So again, the problem only occurs if you (a) try to load a mixed-mode assembly, or a module containing a mixed-mode assembly, that was (b) built for .NET 2 or 3.51, in (c) PowerShell v3. And there shouldn't be a ton of modules out there that hit all three criteria... and many of those will be Windows OS-related modules (mainly because so much of their underlying code is native code, rather than managed code). But there's still a solution.
powershell.exe -version 2.0
If PowerShell v2 is already installed, and you install v3 "on top" of it, you're actually installing v3 "side by side," and it gives you the ability to launch the shell in "v2 mode." This capability specifically addresses this problem, ensuring that you can continue to run older modules that were built against v2 or v3.51 of the Framework. So just boot up the shell in v2 mode and try again.
Is there a way to tell which version a module wants? Usually. Go into the module's folder and look for a .psd1 file - that's the module's manifest. It's just a text file - open it up and you should see something like this:
# The minimum version of PowerShell needed to use this module.
PowerShellVersion = '2.0'
# The CLR version required to use this module.
CLRVersion = '2.0'
That's the PowerShell version and .NET Framework version that the module wants. That doesn't mean the module won't load in a newer version, because it might - but if it doesn't, try running it in the version specified.
You could also set up a custom endpoint (my Remoting Guide covers that) using PowerShell v3, and configure the custom endpoint to run PowerShell v2. That'd let folks on other machines use PowerShell Remoting to connect to the v2 endpoint, either with the PowerShell console or the PowerShell ISE, and run 2.0-friendly stuff within that endpoint.
While you're at it, pay close attention to the window title bar when PowerShell opens. If it says "(x86)" you're running the shell's 32-bit engine on a 64-bit computer; 64-bit modules won't load and may not even be visible to the shell. Ditto the reverse: The 64-bit shell can't utilize 32-bit modules, which is why 64-bit versions of Windows include the (x86) shell in the first place.
Apr 24 2012, 04:54 PM