Folks I may have misunderstood what this is. Thought it was a bunch of PowerShell bits, but on closer inspection there seems to be a lot of c files and exes of somewhat dubious purpose? I don't know. Anyway, sorry for the seemingly bogus (in stated purpose at least) repo. A PowerShell repo of snippets would be a good thing!
The title is a bit confusing if you aren't familiar with the needs the author is probably trying to get.
They're likely a sysadmin trying very hard to get around a lot of limitations Microsoft has on their out of box toolsets and to avoid home-rolling a lot of solutions in more challenging languages.
So a combination of C files, executables, and PS scripts is pretty normal for such an environment. The C/.exes are likely because there are usually pretty obvious walls in Powershell once you're reaching the limit of what PS is meant to do; if most of your code is just .NET, probably you should be writing a small .NET app instead of trying to do it through powershell; given that it's not always easy to just execute a PS script on end-user environments depending on the GPOs and other security items, probably the author has just written some very common workflows that were too annoying to do manually, not worth the effort for a fully functional program, but needed more than what Windows returns normally to Powershell.
I'd say the author is on the far end of the Powershell User spectrum, as the tooling is pretty good, and it's clear from the use-cases they list that they are really trying to administrate their Windows boxes very personally but without having to click around the UI a ton. Many of the scripts are just to get around windows' permissioning and access control
As a side note, you can literally write a C# program and run it inside PowerShell without installing the normal .NET toolchain. Add-Type can accept a string with C# source code and it'll build on-the-fly and load it into your PowerShell environment. And from the C# code you can P/Invoke C functions if you need.
Once you've loaded it up, you can use it directly from PowerShell. I've done this in a pinch and then wrapped it up in a normal PowerShell cmdlet to do things that weren't available from PowerShell otherwise and without needing a .NET build workflow, without needing to store .DLLs, etc. In OP's situation that's what I'd be doing instead of building .DLLs.
I love on Hacker News you can start off thinking think you’re right, and then realize your wrong, but then later on you discover that actually you were right in the first place, when another level of expert commenter has been unlocked by the topic. Haha! :)
