multi-pwsh 0.7.0 is out with initial #PowerShell virtual environment (venv) support, through runtime hooking of PowerShell, PowerShellGet and PSResourceGet! Try it out now, let me know what you think 👇
github.com/Devolutions/...
multi-pwsh 0.7.0 is out with initial #PowerShell virtual environment (venv) support, through runtime hooking of PowerShell, PowerShellGet and PSResourceGet! Try it out now, let me know what you think 👇
github.com/Devolutions/...
Just the FYI while they do use it for parameters to to avoid accidentially logging or to mask input for mandatory params that are "sensitive" the PSRemoting special case was removed in 7.6 github.com/PowerShell/P.... It's still special cased on Windows when serialized as CLIXML though.
Published a new module called AvaloniaUIShell, (the world's first?) cross-platform desktop GUI framework for PowerShell.
github.com/mdgrs-mei/Av...
It's using the same mechanism as WinUIShell and takes care of all threading and non-blocking UI operations.
#PowerShell
I would highly recommend using uv. Can manage Python installs as well as venvs and package installations. I’ve not used it on Windows yet but it’s streets ahead on nix and has replaced pyenv, pip, venv (at least the cli) for me in one nice and fast tool.
I think pwsh is trying to move away from marker vars like this. It’s slightly longer but there is now [Environment]::IsPrivilegedProcess you should be able to use now learn.microsoft.com/en-us/dotnet...
Yea Windows unfortunately has this problem, sorry based on your description I thought it was for *nix
You can always create a symlink in usr bin or local bin for your pwsh versioned suffixes. Ultimately the only builtin thing is pwsh and pwsh-preview and even then the rc releases seem to blur the lines between the 2.
I cleaned up, modernized and improved an old pet project of mine: a .NET native host in Rust that can load and call PowerShell *in-process* from its install path, without a copy of the PowerShell SDK: github.com/Devolutions/...
This is relatively new (7.3 or so) and is part of PowerShell predictors framework. PSReadLine is the one that actually implements it and does use your history. It's not part of the terminal/vscode here learn.microsoft.com/en-us/powers...
While I can’t convince people to like the syntax as it’s always a personal thing, what can cmd do that PowerShell can’t? There is very limited builtin commands to cmd and everything else is an executable that PowerShell can’t also call.
Interesting that x64 didn't work on arm64 as arm64 should be able to run x64 binaries in an emulated mode. I don't know too much about the Platform CPU mode though but hopefully you can figure it out eventually.
If you hate . so much you can call it with & :)
What's special about WebView2 that stops it from working?
WinUI 3 window with basic controls that was created from PowerShell.
Released WinUIShell v0.11.0 that uses the latest stable WindowsAppSDK 1.8.260209005. (Probably) All controls except WebView2 are supported.
Check out the examples to see what's possible!
github.com/mdgrs-mei/Wi...
#PowerShell
Just an FYI authenticode has the concept of timestamp signatures. The underlying cert may have expired but if it contains a signed timestamp during the validity period then the signature is still valid.
Heh sounds like the opposite problem I have. Glad that it looks like they might be solving that problem there.
GitHub Nuget would be great but it doesn't allow anonymous access so not good for end users wanting to install our module. GitHub OCI would be a nice option but PSResourceGet cannot publish or install from any OCI based repo that isn't ACR or MAR. I'm hoping to submit a few PRs to fix that though.
At work we need to publish a PowerShell module but didn't want to deal with PSGallery tokens and more permissions we need to audit over time. I've tried out GitHub Container/OCI and Nuget feeds as well as Azure Artifacts. github.com/jborean93/Po...
TLDR: Use Azure Artifacts.
PowerShell is a shell that runs in a terminal. They aren’t comparable and PowerShell can run in any terminal application and any terminal application can run any shells/console binaries.
Over the past couple of months I've grown increasingly concerned around the future of PowerShell. It seems like the days of community involvement are getting less frequent so I wrote github.com/PowerShell/P.... Would love anyone else to share their thoughts if they wish to.
If anything the pwsh side has more deps because now you have to include the pwsh runtime + the extra assemblies it ships with.
What’s the difference between pure powershell and pure C#. At some point you have your own code. You of course gave this problem if you pull in extra assemblies but the dame problem applies as to whether you do it with pwsh or C#.
As for damage I don’t think it really does over time. It’ll be just as susceptible to runtime differences but if anything it’ll be more resilient because more is checked at compile time and tools are better suited towards validating/refactoring than what pwsh and other dynamic types offer.
It’s mostly simple to do TryGet* like operations with if statements on dynamic types but even then for XML/JSON/other structured formats you typically have pretty good pattern matching abilities and even more that pattern matching is validated at compile time.
While PowerShell still has its place I see it being less and less important/useful as languages like C# and LLMs overcome the historical weaknesses of strictly types languages. The backing from MS has also been somewhat lacking which has reduced my enthusiasm in the product.
… generators have removed a lot of the dynamic nature and thus makes it easier to even require the runtime to be present.
Everything in general, the only positive I see with scripting language is the lower barrier for running from nothing. The performance, feedback loop, IDE environment, content, and community, strictly typing is typically better. With LLMs you can easily regenerate the code needed and source …
In the past I might have agreed with you but strong typing is a massive positive here. It shortens the dev loop, helps catch more issues before running the code and with LLMs it’s a lot easier to generate and prototype the code. I’ll concede it’s easier to run a script than build the code.
With modern pattern matching and type checking C# is so much better than PowerShell. Add in Spans that take away all the copies of objects and it just flies. There’s no way PowerShell would be faster here unless you are doing something really weird in C#.
Cooking a major update to WinUIShell.
I've just finished fixing all the build errors caused by my C# source generator. Thanks to that, all WinUI3 controls will be supported in the next release. Yes, all of them🎉
This example is one of my favorites, ContentDialog.
github.com/mdgrs-mei/Wi...