-
Notifications
You must be signed in to change notification settings - Fork 54
Running Pash with the PowerShell engine #407
Comments
Is there a particular reason for what you are trying to do? While Pash strives to be API-compatible with PowerShell (after all, a part of our tests runs with both Pash and PowerShell in just different build configurations) you most likely cannot (ever) simply replace the assemblies. Furthermore, it's not exactly clear to me what you mean by »Trying to rename Microsoft.PowerShell.Commands.Utility.dll and Microsoft.PowerShell.Commands.Management.dll«. What exactly are you trying to do here? |
I think @kika123 is saying that if you run Pash on Windows, it actually uses official PowerShell assemblies. That would be bad. |
No, I edit Microsoft.PowerShell.Commands.Utility.dll to Microsoft.PowerShell.Commands.Utility.1.dll for example so the Microsoft PowerShell assemblies are used. @JayBazuzi @ygra There is an API incompatibility somewhere |
Ahh, you're saying that normally Pash uses its own versions of those assemblies, but if you force Pash to use the offical PowerShell versions of those assemblies, it doesn't work. I don't see that as a bug. Is there a real scenario that you think should work, but doesn't work because of what you have found? |
@JayBazuzi I think that compatibility of assemblies would be good, especially as it appears to start. You can try to type commands,but they seem to never execute..It's for workarounding restrictions. The other way is to hook ntdll, but well... |
If you wonder where it can be interesting, it's for Windows UWP apps |
@JayBazuzi: Ok, I missed the implication that the PowerShell assemblies would be pulled from the GAC in that case. And agreed, that's not a scenario we'd support. @kika123: You'd essentially replace Pash's cmdlet implementations by those that belong to whatever PowerShell version you have installed (probably 5 in your case). Pash still targets v2 or v3, so we're likely to miss some of the API that the official command implementations call. I mean, you're still running Pash's engine, just with cmdlets that were never tested on that engine. And again, that's not something that I consider worthwhile to make work. As for UWP apps, I'm not sure I'm getting the point here. Are you saying that while you can reference the PowerShell cmdlet assemblies from an UWP app, you cannot do the same for the actual PowerShell engine? That sounds dubious to me. |
On UWP, PowerShell can only be ran in Core language mode, so you only have access to the PowerShell cmdlets and not the .NET runtime functions(even harshest than Restricted) @ygra |
@kika123 I fear that if you want to use Pash in your UWP application, you'll have to reimplement all the cmdlets you want to use (or at least recompile them with Pash reference if our API matches the PowerShell one at a sufficient level). I see no other path around those restrictions, but we here are ready to help; feel free to create issues about the functionality that is missing in Pash. |
@ForNeVeR There is tons of bugs in Pash :) |
Yes, unfortunately there are :( But we are willing to find and eliminate them all sooner or later. For this one I'll find or create another issue, thank you for reporting. |
And yes, as one of a Pash developers I have to say that currently Pash is not nearly suitable for any production deployment. There is still much work to do. |
Trying to rename Microsoft.PowerShell.Commands.Utility.dll and Microsoft.PowerShell.Commands.Management.dll then trying to start Pash fails.
Pash displays:
Pash - Copyright (C) Pash Contributors. License: GPL/BSD. See https://github.com
/Pash-Project/Pash/
then hangs
The text was updated successfully, but these errors were encountered: