Author Posts

December 6, 2013 at 7:19 am

Having problems with a script that runs OK on my local computer, doesn't run on the server ....
Error message, when running it, logged in remotely on the server, with admin rights:
Exception calling "InvokeMember" with "6" argument(s): "Object does not match
target type."
At E:\Affichage_Borne_FORPRO\Script\prepare-borne_lux.ps1:68 char:2
+ $target.PSBase.GetType().InvokeMember($property,
[system.Reflection.BindingFlag ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : TargetException

Exception calling "InvokeMember" with "6" argument(s): "Object does not match
target type."
At E:\Affichage_Borne_FORPRO\Script\prepare-borne_lux.ps1:68 char:2
+ $target.PSBase.GetType().InvokeMember($property,
[system.Reflection.BindingFlag ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Script extract:
#–Here comes the variable text
$CultureOld = [System.Threading.Thread]::CurrentThread.CurrentCulture #Original culture info
$CultureUS = [System.Globalization.CultureInfo]"en-US" #US culture info

# invoke an object's method using the culture info
function Invoke([object]$m, [string]$method, $parameters)
{
$m.PSBase.GetType().InvokeMember($method, [Reflection.BindingFlags]::InvokeMethod, $null, $m, $parameters,$CultureUS)
}
function GetProperty([object]$m, [string]$method, $parameters)
{
$m.PSBase.GetType().InvokeMember($method, [Reflection.BindingFlags]::GetProperty, $null, $m, $parameters,$CultureUS)
}

December 6, 2013 at 7:45 am

Well, I'm not seeing where you're calling Invoke(), so I can't see what you're passing to $m, but I'm guessing the server doesn't have something that your client has. E.g., Excel?

December 6, 2013 at 8:08 am

Excel is installed on the server, the file opens OK, but there it stops ...

December 6, 2013 at 8:11 am

So, not being there it's a bit tough to troubleshoot, but the error message is telling you that you're passing an invalid object to a method. That's often because either (a) the bits on the server aren't present or (b) they're different than what you're using on the client. All that Office Automation garbage is really COM under the hood – it goes through .NET Interop, and I've personally always found it to be painful.

"Excel is installed on the server" also gave me a little gastrointestinal distress, right then. Just sayin'. 🙂

Maybe the Office development extensions? Kinda just grasping at straws – I don't want to go down this path of telling you to install all this client-based stuff on your poor server...

December 6, 2013 at 8:13 am

This isn't something I've experimented much with, but are the results of $m.GetType() and $m.PSBase.GetType() different? You're calling InvokeMember on the result of $m.PSBase.GetType() , but passing in $m. If there's a possibility of some sort of type mismatch there, then you'd need to be consistent one way or the other, ie:

$m.PSBase.GetType().InvokeMember($method, [Reflection.BindingFlags]::InvokeMethod, $null, $m.PSBase, $parameters,$CultureUS)

# or

$m.GetType().InvokeMember($method, [Reflection.BindingFlags]::InvokeMethod, $null, $m, $parameters,$CultureUS)

December 6, 2013 at 8:15 am

Yeah, good thing to check. It seems as if there's a different version of, or missing bits of, the dev library on the server vs. the client. But Dave's point is good, because as you've realized, PowerShell does a lot of "adaptation" on objects. So for Excel, as an example, you're going through about four layers of code to get to the actual COM object under the hood. It's important to make sure that you're accessing those layers consistently, and that whatever you're passing isn't being translated into some unsupported datatype along the way.