I'm trying to use PowerShell to call some F# code which uses Akka.Net actors.
The F# code works fine in unit testing and when run from the F# interpreter, but when I call the same code from a PowerShell cmdlet I get the following exception:
System.MissingMethodException: Method not found: 'Void Nessos.FsPickler.BinarySerializer..ctor(Microsoft.FSharp.Core.FSharpOption`1<Boolean>,
Microsoft.FSharp.Core.FSharpOption`1<Nessos.FsPickler.ITypeNameConverter>)'.
at Akka.FSharp.Serialization.ExprSerializer..ctor(ExtendedActorSystem system)
at Akka.FSharp.Serialization.exprSerializationSupport(ActorSystem system)
at Namespace.NewActorCmdlet..ctor(Host hostA, Host hostB, Boolean option, UserDetails user) in
E:\Projects\Namespace\NewActorCommand.fs:line 24
at Namespace.StartNewActorCommand.ProcessRecord() in
E:\Projects\Namespace\StartNewActor.fs:line 67
at System.Management.Automation.CommandProcessor.ProcessRecord()
I tried running [Nessos.FsPickler.BinarySerializer]::new.OverloadDefinitions in that PowerShell session to check what methods PS though was available and I get:
Nessos.FsPickler.BinarySerializer new(Microsoft.FSharp.Core.FSharpOption[bool] forceLittleEndian, Microsoft.FSharp.Core.FSharpOption[Nessos.FsPickler.ITypeNameConverter] typeConverter)
First thing I noticed was that the version shown by PowerShell takes an FSharpOption[bool] instead of FSharpOption[Boolean]. I tried modifying the Akka.FSharp code to explcitly pass an Option, but that didn't seem to help.
I'm using FSharp.Core 4.0.0.1 (other links suggested 3.0 had problems).
Has anyone seen anything similar?
Even suggestions about where to look for the problem would be helpful, I'm not sure if the issue is with PowerShell, F# or Akka.Net.
Powershell can be difficult when it comes to matching methods based on parameter types. I've found that sometimes i have to "trick" PS by passing an expression to a method rather than a PS variable. For example $object.method($something.property) instead of $prop = $something.property; $object.method($prop) has worked for me.
In the case of overloaded methods another thing you can do is use Reflection to make sure you've got the method with the right signature. For example:
$mi=$object.gettype().getmethod('TheMethod',#([typeParm1],[typeParm2]))
$mi.invoke($object, #($arg1,$arg2))
And sometimes casting helps: $object.method([typeToMatchMethodSig]$arg1) or maybe even a double cast:$object.method([bool][int]$arg1) In both cases I think you'll have more luck if you pass the cast expression as an argument, rather than assign it to a variable and pass the variable.
I doubt this is the case in the OP, but using [activator]::createinstance(...) can be used with a private constructor.
I usually muck around with it till either something works or I give up.
BTW, you can turn on PS tracing for parameter binding and get a lot of info, which may or may not be useful.
Related
The issue is when I type code like this.
let data = sqlx::query("SELECT id, name FROM test")
.fetch_all(&pool)
.await;
I get an no method named `fetch_all` found for struct `sqlx_core::query::Query<'_, _>` in the current scope error. Following official getting started readme.
This is also applicable to the query_as method. I suspect that for some reason the compiler doesn't "see" sqlx::Query trait methods, but I don't know how to bring them in scope.
Although when I use macro sqlx::query!, .fetch_all does exist.
Also, there is an inconvenience that rust-analyzer LSP tells me that the type of the data variable is std::result::Result<[type error], [type error]>, which removes any possibility of using autocompletion and type checking, other than running (notoriously slow) rust compiler.
P.S. I use PostgreSQL as a database solution, if that may help.
P.S.S. env variable DATABASE_URL is set at the compile-time and is correct, so macros do all of the compile-time validation stuff.
Browsing docs.rs a bit, I found that type sqlx::Query does not even have finalizers other than fetch. As for sqlx::query_as, the trait I was looking for was called PgQueryAs, which actually contains fetch_all, fetch_optional, fetch_one, etc. And adding use sqlx::postgress::PgQueryAs fixed the problem for me.
Despite that, I still don't know a solution for evaluating macros to get decent types in my IDE.
PSVersion: 5.1.17134.858
I haven't done a whole lot of work with Powershell's classes but here's a simple example of what I'm running into:
class xNode{
[uint64]$MyID=0
static [uint64]$ClassID=0
xNode(){
$MyID = [xNode]::ClassID++
}
[String] ToString(){return "xNode: $MyID"}
}
doesn't parse it gives the two errors:line 6 $MyID..., "Cannot assign property, use '$this.MyID'."line 9 ..$MyID", "Variable is not assigned in the method."
I'm trying to use the classes property named $MyID, and this usage appears to be in line with the example given in the help documentation get-help about_Classes, and when I copied their whole example at the end out to a file then tried to run it I was getting the same errors as well for $Head, $Body, $Title,... Of course I can force it to work by adding this.
class xNode{
[uint64]$MyID=0
static [uint64]$ClassID=0
xNode(){
$this.MyID = [xNode]::ClassID++
}
[String] ToString(){return "xNode: $($this.MyID)"}
}
However I'd rather not have to keep typing this. all over the place, is there maybe some environment setting or something I've overlooked?
(Note: to get it to work at the commandline, I also needed to remove all of the blank lines)
However I'd rather not have to keep typing this. all over the place, is there maybe some environment setting or something I've overlooked?
No, it's working as advertised, you can't reference instance properties inside the class without the $this variable reference.
Why do powershell class properties require this within their methods?
(The following is what I'd call "qualified speculation", ie. not an officially sourced explanation)
PowerShell classes are a bit tricky from an implementers point of view, because a .NET property behaves differently than, say, a parameter in a powershell scriptblock or a regular variable.
This means that when the language engine parses, analyzes and compiles the code that makes up your PowerShell Class, extra care has to be taken as to which rules and constraints apply to either.
By requiring all "instance-plumbing" to be routed through $this, this problem of observing one set of rules for class members vs everything else becomes much smaller in scope, and existing editor tools can continue to (sort of) work with very little change.
From a user perspective, requiring $this also helps prevent accidental mishaps, like overwriting instance members when creating new local variables.
In my new project team, for each powershell cmdlet they have written proxy function. When i asked the reason for this practice, they said that it is a normal way that automation framework would be written. They also said that If powershell cmdlet is changed then we do not need to worry ,we can just change one function.
I never saw powershell cmdlets functionality or names changed.
For example, In SQL powershell module they previously used snapin then they changed to module. but still the cmdlets are same. No change in cmdlet signature. May be extra arguments would have added.
Because of this proxy functions , even small tasks taking long time. Is their fear baseless or correct? Is there any incident where powershell cmdlets name or parameter changed?
I guess they want to be extra safe. Powershell would have breaking changes here and here sometimes but I doubt that what your team is doing would be impacted by those (given the rare nature of these events). For instance my several years old scripts continue to function properly up to present day (and they were mostly developed against PS 2-3).
I would say that this is overengineering, but I cant really blame them for that.
4c74356b41 makes some good points, but I wonder if there's a simpler approach.
Bear with me while I restate the situation, just to ensure I understand it.
My understanding of the issue is that usage of a certain cmdlet may be strewn about the code base of your automation framework.
One day, in a new release of PowerShell or that module, the implementation changes; could be internal only, could be parameters (signature) or even cmdlet name that changes.
The problem then, is you would have to change the implementation all throughout your code.
So with proxy functions, you don't prevent this issue; a breaking change will break your framework, but the idea is that fixing it would be simpler because you can fix up your own proxy function implementation, in one place, and then all of the code will be fixed.
Other Options
Because of the way command discovery works in PowerShell, you can override existing commands by defining functions or aliases with the same name.
So for example let's say that Get-Service had a breaking change and you used it all over (no proxy functions).
Instead of changing all your code, you can define your own Get-Service function, and the code will use that instead. It's basically the same thing you're doing now, except you don't have to implement hundreds of "empty" proxy functions.
For better naming, you can name your function Get-FrameworkService (or something) and then just define an alias for Get-Service to Get-FrameworkService. It's a bit easier to test that way.
One disadvantage with this is that reading the code could be unclear, because when you see Get-Service somewhere it's not immediately obvious that it could have been overwritten, which makes it a bit less straightforward if you really wanted to call the current original version.
For that, I recommend importing all of the modules you'll be using with -Prefix and then making all (potentially) overridable calls use the prefix, so there's a clear demarcation.
This even works with a lot of the "built-in" commands, so you could re-import the module with a prefix:
Import-Module Microsoft.PowerShell.Utility -Prefix Overridable -Force
TL;DR
So the short answer:
avoid making lots and lots of pass-thru proxy functions
import all modules with prefix
when needed create a new function to override functionality of another
then add an alias for prefixed_name -> override_function
Import-Module Microsoft.PowerShell.Utility -Prefix Overridable -Force
Compare-OverridableObject $a $b
No need for a proxy here; later when you want to override it:
function Compare-CanonicalObject { <# Stuff #> }
New-Alias Compare-OverridableObject Compare-CanonicalObject
Anywhere in the code that you see a direct call like:
Compare-Object $c $d
Then you know: either this intentionally calls the current implementation of that command (which in other places could be overridden), or this command should never be overridden.
Advantages:
Clarity: looking at the code tells you whether an override could exist.
Testability: writing tests is clearer and easier for overridden commands because they have their own unique name
Discoverability: all overridden commands can be discovered by searching for aliases with the right name pattern i.e. Get-Alias *-Overridable*
Much less code
All overrides and their aliases can be packaged into modules
I have been banging up against this for several hours now and I'm hoping that someone can help point me in the right direction.
I'm developing a few custom PowerShell cmdlets, and one of the supporting classes is a User object. Several of my cmdlets either emit or consume List.
This has worked very well so far, but I hit a serious snag when I tried to serialize one of the lists. The export seems to work fine; I look at the file (csv, clixml, etc.) and it looks the way I expect it to with type User. However, when I re-import it, the type seems to change to CSV:Class.User or Deserialized.Class.User. Obviously, this causes a problem when it's fed into a cmdlet that expects the standard User class.
If there a good way to fix this? I suspected that changing my cmdlets to expect some Interface instead of List would probably do the trick, but I can't figure out what interface that should be. And I can find no switch to the import methods to specify class names.
Any help would be greatly appreciated.
Welcome to PowerShell's extended type system. :-) BTW you will also get back state-only deserialized objects when your objects are passed across a remoting session. You can query the PSObject's TypeNames collection looking for Deserialized.Class.User to determine if you have a deserialized version of your type. Sames goes for the CSV version. You could create a couple of factory methods or clone style constructors on your User class that takes a PSObject that is some type of User (CSV or Deserialized) and then create a regular Class.User object. Just be aware that certain operations may not make sense in the deserialization case. For instance, using a Process object as an example, you can call Kill on a Process object and if the object came from the same machine that would work (assuming correct privs). However, if you were to call Kill on a process object from another machine, that's not going to work - hence the special deserialized objects that are primarily just data (property) containers.
I have been playing around with the dynamic abilities of powershell and I was wondering something
Is there is anything in powershell analogous to Ruby's method_missing() where you can set up a 'catch all method' to dynamically handle calls to non-existant methods on your objects?
No, not really. I suspect that the next version of PowerShell will become more in line with the dynamic dispatch capabilities added to .NET 4 but for the time being, this would not be possible in pure PowerShell.
Although I do recall that there is a component model similar to that found in .NET's TypeDescriptor for creating objects that provide properties and methods dynamically to PowerShell. This is how XML elements are able to be treated like objects, for example. But this is poorly documented if at all and in my experience, a lot of the types/methods needed to integrate are marked as internal.
You can emulate it, but it's tricky. The technique is described in Lee Holmes book and is boiled down to two scripts - Add-RelativePathCapture http://poshcode.org/2131 and New-CommandWrapper http://poshcode.org/2197.
The essence is - you can override any cmdlet via New-CommandWrapper. Thus you can redefine Out-Default that is implicitly invoked at the end of almost every command (excluding commands with explicit formatters like Format-Table at the end). In the new Out-Default you check if the last command threw an exception saying that no method / property was found. And there you insert your method_missing logic.
You could use Try Catch within Powershell 2.0
http://blogs.technet.com/b/heyscriptingguy/archive/2010/03/11/hey-scripting-guy-march-11-2010.aspx