fsprojects/FSharp.Management

PS Type provider type failed with Set-Location

Closed this issue · 6 comments

Description

When use powershell type provider and set-location cmdlet, script fail with a type error

Repro steps

#r "../packages/FSharp.Management/lib/net40/FSharp.Management.dll"
#r "../packages/FSharp.Management/lib/net40/FSharp.Management.PowerShell.dll"
#r "../packages/FSharp.Management/lib/net40/System.Management.Automation.dll"

#r "System.ServiceProcess"
#r "System.Xml.Linq"
#r "Microsoft.Management.Infrastructure"

open FSharp.Management

type PS = PowerShellProvider<"Microsoft.PowerShell.Management;Microsoft.PowerShell.Core;Deployment;Teamcity" >

PS.``Set-Location``(path="""C:\Users\cboudereau""") |> ignore

Set-Location fail with error :

Object of type 'System.Management.Automation.PSObject' cannot be converted to type 'Microsoft.FSharp.Core.FSharpChoice2[Microsoft.FSharp.Collections.FSharpList1[System.Management.Automation.PathInfo],Microsoft.FSharp.Collections.FSharpList`1[System.Management.Automation.PathInfoStack]]'.
at System.RuntimeType.TryChangeType(Object value, Binder binder, CultureInfo culture, Boolean needsSpecialCast)
at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr)
at System.Reflection.MethodBase.CheckArguments(Object[] parameters, Binder binder, BindingFlags invokeAttr, CultureInfo culture, Signature sig)
at System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)

Expected behavior

Maybe convert PS Custom Object to the right object. I know it is a little bit hard to infer powershell type result but with the version 0.3.1 it works with the option type

Actual behavior

Fail to convert expected type from ps custom object

Known workarounds

Revert to the version 0.3.1

Related information

  • Operating system win10
  • .NET Runtime 4.5.1

By setting the parameter passThru to true it works fine. I don't know why when the parameter is not set the type change. Maybe a powershell dynamic type.

@Firgeis do you know why this may happened?
The only change in 0.4.0 is #66

Well looking at the Cmdlet OutputType (which we use to determine the type of the response), it reports that it should return one of these types:

System.Management.Automation.PathInfo
System.Management.Automation.PathInfoStack

However when we look at the PassThru parameter doc we find that:

"Returns a System.Management.Automation.PathInfo object that represents the location. By default, this cmdlet does not generate any output".

My guess that this is fooling the type provider into trying to cast an invalid object when this is not set in this lines:

let boxedResult = new PSObject(result)
cmd.ResultType.GetMethod("NewSuccess").Invoke(null, [|boxedResult|]) // Result of execution is empty object

I believe i'll have a fix by tomorrow

Cool!

Many thanks!

On Aug 19, 2016 3:37 PM, "Ezequiel Lewin" notifications@github.com wrote:

Well looking at the Cmdlet OutputType (which we use to determine the type
of the response), it reports that it should return one of these types:

System.Management.Automation.PathInfo
System.Management.Automation.PathInfoStack

However when we look at the PassThru parameter doc we find that:

"Returns a System.Management.Automation.PathInfo object that represents
the location. By default, this cmdlet does not generate any output".

My guess that this is fooling the type provider into trying to cast an
invalid object when this is not set in this lines:

https://github.com/fsprojects/FSharp.Management/blob/
ad4164e/src/FSharp.Management.PowerShell/
HostedRuntime.fs#L131-L132

I believe i'll have a fix by tomorrow


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#73 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB_rV2Eg7fcV_Ji78tI3BYgdahBnNBjHks5qhbGFgaJpZM4JlN7V
.

Should be fixed in v0.4.2
Thank you @Firgeis

Thank you!

On Aug 21, 2016 1:35 PM, "Sergey Tihon" notifications@github.com wrote:

Closed #73 #73.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#73 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB_rV9orchclIlYB5TsNFIXqhtp318Knks5qiDf3gaJpZM4JlN7V
.