Programmatic use of Powershell Import-Module fails

Hi all,

I've just start to try out Win 8 and have come across a problem with use of Powershell from C#. When trying to run the following in a pipeline:

Import-Module -Name ServerManager

a failure is reported that states that the module cannot be loaded due to the manifest containing one or more invalid members. In this case it's the HelpInfoUri that is causing the problem. I did some trawling and found out that this exact same problem was reported for the Win 8 Client.

Is there a workaround that allows v3.0 of Powershell to be used by the C# code (which will load the module as that appears to be what happens when running powershell.exe) rather than v2.0?

Edit: Forgot to mention, this is with the code compiled to .Net v3.5 rather than v4.0 (which works).

Cheers!


  • Edited by rob.q Friday, March 09, 2012 4:59 PM Extra info added
March 9th, 2012 4:47pm

Windows PowerShell in Windows Server 8 Beta implements dynamic module loading. Using the Import-Module cmdlet is no longer required; instead, simply invoking the cmdlet, alias, or function automatically loads the module. 
  • Marked as answer by Tiger Li Tuesday, March 13, 2012 5:30 AM
  • Unmarked as answer by rob.q Tuesday, March 13, 2012 3:33 PM
Free Windows Admin Tool Kit Click here and download it now
March 10th, 2012 6:57am

Actually this doesn't work in a programmatic environment, for example, attempting to execute the cmdlet "Get-WindowsFeature" results in a CommandNotFoundException being raised, whereas when run from powershell.exe it does work as stated.

The problem I am seeking an answer to is how to get a program that calls powershell using the C# api, that has a need to be compiled under .Net 3.5 such that it can run on non- .Net 4 powershell 3.0 environments and has a supportedRuntime element in its config file set to v2.0, to work when it tries to import a module when it happens to be run on a .Net 4 powershell 3.0 environment that has .Net 3.5 installed, like Windows 8 Server Beta.

March 13th, 2012 3:39pm

I managed to answer my own question here. In the .Net config file associated with the C# in question, if you add

<startup><supportedRuntime version="4.0"/><startup/>
to the file, it just works. I am assuming that this relies entirely on the capability of .Net 4.0 to interoperate correctly with .Net 3.5 compiled libraries.
  • Marked as answer by rob.q Monday, March 26, 2012 5:28 PM
Free Windows Admin Tool Kit Click here and download it now
March 26th, 2012 5:28pm

It did not work for me. Any alternative?
April 24th, 2015 3:22pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics