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?
-
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?
I also avoid PowerShell, it's of no use to me either.
-
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?
This is very welcome news. I might just want to learn PowerShell after all just for this capability.
The difficult we do right away... ...the impossible takes slightly longer.
-
This is very welcome news. I might just want to learn PowerShell after all just for this capability.
The difficult we do right away... ...the impossible takes slightly longer.
-
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?
I tried PowerShell a couple of times, but I agree that for a C# programmer the syntax is really awful.
-
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?
If all your business logic is C#, and you just read it in PS, you can't step through that code to debug it. Of course if that's already been thoroughly tested and you're dropping it in as-is, then it's not much of an issue. PS can create/use the same .NET objects you're familiar with natively. Yes, the syntax can be non-intuitive at first, but once you get the hang on it, the benefit of being able to bang out a short script to automate some menial task beats having to fire up VS and build/compile an EXE every time you want to make a tiny change.
-
If all your business logic is C#, and you just read it in PS, you can't step through that code to debug it. Of course if that's already been thoroughly tested and you're dropping it in as-is, then it's not much of an issue. PS can create/use the same .NET objects you're familiar with natively. Yes, the syntax can be non-intuitive at first, but once you get the hang on it, the benefit of being able to bang out a short script to automate some menial task beats having to fire up VS and build/compile an EXE every time you want to make a tiny change.
PS syntax is not intuitive. It is awful to work with. What I do is create a C# library DLL project, and write unit tests for the class(es). Then I include my ps1 file, which I can run from within VS by using the PS ISE, which loads the cs file. That gives me good source control, good testing, and minimal “script kiddie” coding. C# is far more versatile and elegant with which to code. Since our team standardized on PS long before I got there (DevOps stuff), it then is compatible with what others are doing by staying within the PS world.
-
Powershell+C#=cryptic^2 sorry no interest
"A little time, a little trouble, your better day" Badfinger
Cryptic only if you are not familiar with C#. For someone who is used to the 40+ year old approach of scripting shells, they might find it easier to stay with scripting. And if you don’t have to use scripting shells - don’t. It is a backwards way to get work done. But, in my case, I have no choice. Trying to convince a DevOps team they do not need scripting is a lost cause.
-
I tried PowerShell a couple of times, but I agree that for a C# programmer the syntax is really awful.
Years ago I wrote a C# DLL that allows my programs to take in raw C# cs files and run them as scripts. Why PowerShell was created without the ability to natively use C# for scripting instead of that inane verb-noun syntax with the cryptic parameters is beyond me.
-
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?
You could also call .NET from PS. That way, you don't mix 2 languages. .NET methods don't look perfectly not-out-of-place in PS but the result will still be way more maintainable than calling C# files from PS.
-
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?
Even though PowerShell has a not so great syntax, it's a god-tier shell. You can call bash from PS whenever you need UNIX tools. You can call .NET from PS whenever you need to configure anything system wise. Anything. You can call the Windows Store when you need to install anything vaguely supported by Microsoft. You can use those god-awful Node-esque scripts when you need to transpile/polyfill something front-end related. You can patch system level .dll's to enable advanced remoting features. You can remote from anything into anything. Only downside is the security. If you listen to Microsoft, they will tell you they have experts that understand and patch common vulnerabilities quickly. If you actually use it for a couple of years, you'll quickly notice their understanding of security resembles covering their ears and yelling "lalala I can't hear you" very loudly.
-
Even though PowerShell has a not so great syntax, it's a god-tier shell. You can call bash from PS whenever you need UNIX tools. You can call .NET from PS whenever you need to configure anything system wise. Anything. You can call the Windows Store when you need to install anything vaguely supported by Microsoft. You can use those god-awful Node-esque scripts when you need to transpile/polyfill something front-end related. You can patch system level .dll's to enable advanced remoting features. You can remote from anything into anything. Only downside is the security. If you listen to Microsoft, they will tell you they have experts that understand and patch common vulnerabilities quickly. If you actually use it for a couple of years, you'll quickly notice their understanding of security resembles covering their ears and yelling "lalala I can't hear you" very loudly.
is it possible for you to write up a post on this topic?
diligent hands rule....
-
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?
-
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?
*shudder* PS is for scripting and for automation. It to me was just another language that could enable me to do a few more things than a bat file did and it was going to be "more" supported by MS going forward. C# is a programming language that you make things(objects) out of. you can call .net objects from PS and that is what PS is for. Keep C# where it belongs and PS where it belongs. I really think too often we all(myself included) get stuck in our ways and avoid learning something new just because at fist glance we don't like it. PowerShell is just another technology. Once learned you will see some benefits. Granted C# is more powerful. But each has their purpose in the MS exosphere.
To err is human to really elephant it up you need a computer
-
You could also call .NET from PS. That way, you don't mix 2 languages. .NET methods don't look perfectly not-out-of-place in PS but the result will still be way more maintainable than calling C# files from PS.
I find it easily maintainable.
-
is it possible for you to write up a post on this topic?
diligent hands rule....
Thanks for the suggestion. I’ll see if I can find the time while on vacation in a couple of weeks.
-
*shudder* PS is for scripting and for automation. It to me was just another language that could enable me to do a few more things than a bat file did and it was going to be "more" supported by MS going forward. C# is a programming language that you make things(objects) out of. you can call .net objects from PS and that is what PS is for. Keep C# where it belongs and PS where it belongs. I really think too often we all(myself included) get stuck in our ways and avoid learning something new just because at fist glance we don't like it. PowerShell is just another technology. Once learned you will see some benefits. Granted C# is more powerful. But each has their purpose in the MS exosphere.
To err is human to really elephant it up you need a computer
PS is built on .NET and uses objects. Think of the approach I use the same principle as separating business logic from UI logic. I separate the business logic (much better done in C#) from the scripting logic (simpler work better done in PS).
-
PS syntax is not intuitive. It is awful to work with. What I do is create a C# library DLL project, and write unit tests for the class(es). Then I include my ps1 file, which I can run from within VS by using the PS ISE, which loads the cs file. That gives me good source control, good testing, and minimal “script kiddie” coding. C# is far more versatile and elegant with which to code. Since our team standardized on PS long before I got there (DevOps stuff), it then is compatible with what others are doing by staying within the PS world.
-
PS is built on .NET and uses objects. Think of the approach I use the same principle as separating business logic from UI logic. I separate the business logic (much better done in C#) from the scripting logic (simpler work better done in PS).
-
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?
I love to see another cohort participating in such crimes against humanity.:laugh: This reminds me of about 10 years ago when I cut my teeth with PS at a bank I worked at. I had ended up building a whole Console app AutoUtils.exe in VB.NET for handling day to day maintenance on the dev and QA environments as well as some security auditing functions via Batch files. After the bare metal server migrations to VMs in a blade rack a few months later, IT Jesus decided suddenly PS was king and the only accepted tool for scripting. I left there before I got the chance to rewrite the AutoUtils as PS scripts. But the ability to consume .net appcode directly in PS was something I was excited to leverage. At my last job, our senior started establishing devops practices and the number of servers between our 2 datacenters was significant. He started using PS with C# helpers for handling specific build workflows between environments and datacenters. Last time I talked to him, he uses it at his new job unraveling several years of user induced "point and click" workflows that had no need being manual. Told me he has written several C# helpers. No shame in using what works for your use case.
