interesting "issue" or "bug" with psobjects when calling DOTNET framework stuff

so in a previous issue, we were having cases where we had an object,
spotwelded on some properties with addmember (which is stored in the
psobject wraper, not the actual underlying object whether it be a
fileinfo, process or whatever object)... then we call a native dotnet
method to add it to an arraylist.. the problem was when we retrieved
this object from the arraylist, the properties we added were gone..

the issue is i think, that powershell when calling a native dotnet api,
just passes in the baseobject, rather than the psboject, and thus any
such customisations will be gone... i got around this by rather storing
the psobject in an array.. with $list.add(,$item) then stripping that
out later.. but its still a hack

to make sure this was a problem with any dotnet call, not just
arraylist i made this small C# class..

public class testclass
{
public object justreturntheobject(object inobj)
{
return inobj;
}
}

basically it does nothing but take in an object and return the same
thing..

then i did thisL
[reflection.assembly]::LoadFile("c:\personal\projects\MSHAnalzyer\MSHAnalzyer\bin\Release\PSbugTest.dll")

$test = new-Object psbugtest.testclass

$temp = (gci)[1]
$temp = add-member -input $temp -passthru -member noteproperty -name
prop -value 10
$temp.prop

$temp2 = $test.justreturntheobject($temp)
$temp2.prop

i can tell that $temp had the spotwelded property, but $temp2 that came
from the call to my C# class didn't..

the problem is you are passing the powershellobject to a native dotnet
class, and i think in that case they will always pass the underlying
baseobject, rather than the powershell psobject, because the dotnet
framework doesn't know how to deal with psbojects i mean if the dotnet
object method was expecting a string, it would die if it actually got a
psobject.it wouldn't know what do to.. so psobjects will work in the
context of cmdlets, and functions because they are running in the
context of powershell, so powershell knows how to deal with them,
however get to the underlying class as needed

i think there is no way around this.. but its one of those GEM GOTCHAS
that we need to collection and have in some sort of FAQ. maybe it would
be good to have a function that will preserve a psobject so that we can
purposely pass in a psobject to native dotnetcommands when we want.

another thing i have been thinking about for some time is building a
bunch of cmdlets specifically to deal with collections in a more
powershelling way.