PowerShell 4.0, Load .NET Assembly

PowerShell Help
1

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:
[System.Reflection.Assembly]::LoadWithPartialName
[System.Reflection.Assembly]::LoadFrom(“C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.ServiceModel.dll”)
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
Serialization 1.1.0.1
CLRVersion 4.0.30319.34014
BuildVersion 6.3.9600.17400
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2

2

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.

3

Kahlan,

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

4

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:

param($Tokens)

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

5

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

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

6

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!