PowerShell AND C#
-
I am starting to learn PowerShell. I have avoided it for years, because whatever I needed to do beyond a simple BAT file, I could do in C#. However, I am in a situation where I have to use PowerShell, so I am learning it. One of the things I learned is that within a PowerShell script, you can call .cs files to run C# code. So this question came to mind, and I thought you all might have some opinions. I wrote a PS script that calls a .cs file and does exactly what I described. I have not mastered calling non-GAC .NET library DLLs yet, but I am working on it. Why not use PowerShell as a management script, and write C# code to execute the "business logic"? I am not convinced that it is better to use PowerShell cmdlets to hack up some brittle script to do what can be more easily done in C#, which is far more capable and wider-ranging than PowerShell script. This is a snippet from my script:
## Load the C# code file
Namespace PSTest
Class SomeCSClass
$Source = Get-Content "SomeCSClass.cs" -Raw
Add the class(es) from the C# code to use
Add-Type -TypeDefinition $Source
Instantiate the object(s)
$TestDLL = New-Object PSTest.SomeCSClass
Build the path for test files (non-static method)
$TestFilePath = $TestDLL.GetCurrentDirectory() + "\PowerShell Example Files\"
Get a list of files using C# code from a static method
$Files = [PSTest.SomeCSClass]::GetListOfFiles($TestFilePath, "*.txt", 0)
Your thoughts?
In speaking with a security expert. His #1 recommendation was to disable PowerShell! He said about 80% of the FILELESS (undetectable) infiltrations use PowerShell. Since I was not a big user of it, I simply disabled it. It would be TOUGH for me to enable it. Just an interesting point!
-
Written in C#, uses .NET, but the syntax is nothing like C#. IMHO, they would have been better off creating a C# library for static commands that are now verb-noun syntax and keeping the familiar C# syntax.
-
Written in C#, uses .NET, but the syntax is nothing like C#. IMHO, they would have been better off creating a C# library for static commands that are now verb-noun syntax and keeping the familiar C# syntax.
If you think about the C# to open a process and pass it arguments, the Powershell syntax is less verbose than that would be. Part of it is they started kicking around together as kids and since neither was an adult it's a lord of the flies sort of deal. (Much respect to both, but not giving up the metaphor.) C# only not terribly long ago (C# 3/4, respectively) added var/dynamic that would enable some of what powershell is doing with sticking command results into objects. The typical problem space (system administration/networking/security?) also has all these concerns that you simply do not have with the majority of what C# code out there is doing. I'm not saying I wouldn't love it if it PowerShell were more C#-y and less whatever it is. But I do see challenges and reasons not to simply say "let's make it a C# console that sends input (script file or otherwise) straight to IL and onwards to a shell-specific runtime". Nowadays? Even if the guy tasked with and enabled to undertake a massive re-write of PowerShell looked at the state of things and decided that approach was a really good way to go? Well you've got all this baggage that plane simply wouldn't carry. There are probably many many folks less C# dev and more really smart scripter-admins (or wanting nothing to do with writing any of it) who depend on what's there and if you pulled the rug in the name of "code sanity" they would be very unhappy. Maybe it would be possible for the interpreter to detect "old-style" vs "new" and translate the old stuff on the fly...
-
If you think about the C# to open a process and pass it arguments, the Powershell syntax is less verbose than that would be. Part of it is they started kicking around together as kids and since neither was an adult it's a lord of the flies sort of deal. (Much respect to both, but not giving up the metaphor.) C# only not terribly long ago (C# 3/4, respectively) added var/dynamic that would enable some of what powershell is doing with sticking command results into objects. The typical problem space (system administration/networking/security?) also has all these concerns that you simply do not have with the majority of what C# code out there is doing. I'm not saying I wouldn't love it if it PowerShell were more C#-y and less whatever it is. But I do see challenges and reasons not to simply say "let's make it a C# console that sends input (script file or otherwise) straight to IL and onwards to a shell-specific runtime". Nowadays? Even if the guy tasked with and enabled to undertake a massive re-write of PowerShell looked at the state of things and decided that approach was a really good way to go? Well you've got all this baggage that plane simply wouldn't carry. There are probably many many folks less C# dev and more really smart scripter-admins (or wanting nothing to do with writing any of it) who depend on what's there and if you pulled the rug in the name of "code sanity" they would be very unhappy. Maybe it would be possible for the interpreter to detect "old-style" vs "new" and translate the old stuff on the fly...
I am not advocating to change it. It is too late. They missed the boat on making PS something good for non-developer DevOps folks and for C# developers. But it would be great if they would simply streamline the way a .NET DLL, not in the GAC, is loaded for use. My reason for this is be able to apply a separation of concerns - administrative (PS script) vs business rules (C#).
-
I am not advocating to change it. It is too late. They missed the boat on making PS something good for non-developer DevOps folks and for C# developers. But it would be great if they would simply streamline the way a .NET DLL, not in the GAC, is loaded for use. My reason for this is be able to apply a separation of concerns - administrative (PS script) vs business rules (C#).
Yes, makes sense maybe. I suppose without getting into the weeds of it, my knee-jerk would be that if business rules are branching scripting logic then maybe it is anywhere from not awful to preferential for them to live as a part of it. But I picture a scenario like you are a cloud host and depending on client tier you want to spin some resources up on group A vs group B hardware (more muscle). You might call into C# to get that client tier, but based on the result the A/B specifics are part of the script.
-
is it possible for you to write up a post on this topic?
diligent hands rule....