PowerShell 4.0, Load .NET Assembly

This topic contains 5 replies, has 3 voices, and was last updated by Profile photo of Kahlan Amnell Kahlan Amnell 1 year, 3 months ago.

  • Author
  • #27011
    Profile photo of Kahlan Amnell
    Kahlan Amnell

    I have a PowerShell script which loads some .NET assemblies specifically System.Runtime.Serialization, System.IO, and System.ServiceModel.

    I have already tried using the following:
    Add-Type -AssemblyName System.ServiceModel
    Add-Type -Path "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.ServiceModel.dll"

    All works if I execute my script from PowerShellI ISE but when when called from a Run .NET Activity of an Orchestrator runbook, it fails with this error:

    Could not load file or assembly 'file:///C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.ServiceModel.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

    I thought this is only an issue if I'm using PowerShell v2.0 and using PowerShell v3.0 would fix the problem? And I assumed that it's also not an issue with v4.0.

    If it helps, this is what I get if I type $psversiontable in PowerShell Console:

    PSVersion 4.0
    WSManStackVersion 3.0
    CLRVersion 4.0.30319.34014
    BuildVersion 6.3.9600.17400
    PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
    PSRemotingProtocolVersion 2.2

  • #27012
    Profile photo of Don Jones
    Don Jones

    What you're testing isn't replicating the problem.

    Different versions of PowerShell can run against multiple different versions of the .NET Framework. What's important is what version of .NET is Orchestrator running? Orchestrator can't load assemblies from multiple different build versions.

    Yes, the PowerShell console works for you, as does the ISE, but they are obviously built against a different version of .NET than what Orchestrator is using. This really has nothing to do with PowerShell; it's .NET and Orchestrator. You need to find out what version Orchestrator is using, and make sure you're loading assemblies built against that same version.

  • #27022
    Profile photo of Tim Curwick
    Tim Curwick


    Orchestrator is, quite annoyingly, still a 32-bit program. So when it launches PowerShell, it launches the 32-bit version of PowerShell. When you try to load a 64-bit assembly into a 32-bit session, it fails, as you discovered.

    Try loading the 32-bit version of the .dll.

    Or wrap your PowerShell code in a call to PowerShell. This will launch a second PowerShell session, which will be in the right version.

    I recently wrote a related article. http://www.madwithpowershell.com/2015/06/64-bit-vs-32-bit-powershell.html

  • #27025
    Profile photo of Kahlan Amnell
    Kahlan Amnell

    Thank you both, this pointed me to the right direction. Orchestrator does load the version 2 of the PowerShell. Now I'm trying to use Invoke-Command to execute my PowerShell script file but unable to pass the parameter I need. My PowerShell script is like:


    function Main($Tokens)
    //some logic iterating through $Tokens which is actually a dictionary

    Main -Tokens $Tokens

    And then this is my Invoke-Command

    $MyTokens = @{}
    $MyTokens.Add("1", "one")

    Invoke-Command {param($Tokens) C:\migration_scripts\mailmigration.ps1 } -ArgumentList $MyTokens

    The file does get called but it doesn't seem like the parameter is getting passed to it

  • #27026
    Profile photo of Don Jones
    Don Jones

    Invoke-Command {param($Tokens) C:\migration_scripts\mailmigration.ps1 -Tokens $Tokens } -ArgumentList $MyTokens

    You weren't actually passing the variable to the script.

  • #27027
    Profile photo of Kahlan Amnell
    Kahlan Amnell

    Oh I see what you're saying. This works in ISE but not in my Run .NET activity. It says

    You must provide a value expression on the right-hand side of the '-' operator.

    Which is weird. Anyway, this again is something on Orchestrator. Thank you very much for your help!

You must be logged in to reply to this topic.