|
Thanks for the suggestion. I’ll see if I can find the time while on vacation in a couple of weeks.
|
|
|
|
|
Yes.
I've been wanting to write something, might as well be this.
|
|
|
|
|
|
*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).
|
|
|
|
|
IIRC, Powershell is written/implemented in C#.
|
|
|
|
|
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...
|
|
|
|
|
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.
|
|
|
|
|
I love to see another cohort participating in such crimes against humanity. 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.
|
|
|
|
|
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!
|
|
|
|
|
Wordle 377 4/6
⬜⬜🟨⬜🟨
⬜⬜🟨🟨🟨
🟩🟨🟨🟨🟨
🟩🟩🟩🟩🟩
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Lesley posted that over 12 hours ago ... still on the same page ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I know. Cut me some slack. just trying to get this wordle sharing thing down
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
We never cut slack on Leslies!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I recently implemented a small service to handle uploads from the browser to our "media server" (rather legacy, don't ask) and on our dev server, no problem. On the actual media server box, I kept getting the dreaded no-access-control-allow-origin header.
Fussed with all the IIS settings and web.config settings to no avail.
Tested vanilla POST calls, all passed CORS without issues.
Learned about "simple requests" which multiform is one of and which don't do an OPTIONS preflight request.
Found an obscure post that people were getting this CORS error on ngnix when the file size was too large.
Tried uploading a a 1K file, and it worked!
Discovered that if the file size was somewhere between by 31K and 67K test files, the larger one failed.
Discovered that if I removed the docInfo parameter:
public IActionResult Upload([FromForm] DocumentUpload docInfo)
The endpoint was hit, no CORS error.
Was thinking, geez, what is .NET 6 doing? Do I have to parse the multiform data myself?
Found a post on the topic that mentioned this code:
var form = ControllerContext.HttpContext.Request.Form;
Tried that and to my horror, it threw an UnauthorizedAccessException that c:\windows\temp\[temp file] is not accessible.
Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp.
AND IT WORKED.
Unbelievable. An unauthorized access exception results in the browser giving me a CORS error!
This took all week to figure out, spending probably 6 hours a day on it. 
And the small <30K file uploads worked without problems because it didn't require creating a temp file for the stream content.
|
|
|
|
|
I have no idea what you're talking about  other than the punch line, which seems to be that this house of cards is shite at generating error messages that are useful for debugging.
|
|
|
|
|
Greg Utas wrote: seems to be that this house of cards is shite at generating error messages that are useful for debugging
It's ALWAYS been this way. SQL Server is the worst.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I know what an SQL server is but had no idea the post was talking about one.  
|
|
|
|
|
Hmmm,
Marc Clifton wrote: Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp.
AND IT WORKED.
Are you sure that allowing your application pool to use global %TEMP% is a good idea? Everybody can read/write to that location. It's probably more secure if your application pool uses the %USERPROFILE% temp path.
I'm not an IIS expert but I think a better fix would be loading the user profile[^] for the application pool identity. You should dig around for a setting to enable that. This setting will populate your environment variables and should change your temp folder to the %USERPROFILE% temp.
Just a security recommendation. 
|
|
|
|
|
Agreed - the main point being, the absurd journey it took to discover that this was all the result of not being able to access the temp folder that .NET (or something?) was trying to use to buffer the files being uploaded.
|
|
|
|
|
I've had something similar before with something going wrong on the API, but the browser showing it as a CORS error. There's a whole flow that happens and I assume that the initial CORS request fails due to whatever is wrong in the background and the browser then just shows that CORS failed.
On a ASP.Net project I had to put a if statement in for handling CORS Options requests from Angular because it was calling the method like it would have with a normal request. Maybe just a weird setup in my case. With .Net Core I don't think the options request activates the breakpoints, although it looks like you can with some middleware: https://www.codeproject.com/Questions/5162494/Currently-I-am-working-on-angular-and-web-API-NET
Complete Guide to CORS
modified 1-Jul-22 8:17am.
|
|
|
|
|
Fantastic & interesting post & great detective skills. 
Marc Clifton wrote: Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp.
I'm filing this one away in my brain for later use.
That is a crazy situation but I totally believe it because of horrors I've seen with similar & IIS & CORS etc.
BTW, was this change needed only on your dev box or did you have to make that change on the Server also?
This is just crazy to me. Can you post the link where you found that solution? Very interesting and quite terrible.
|
|
|
|
|
raddevus wrote: was this change needed only on your dev box or did you have to make that change on the Server also?
I've never had to make this change anywhere, whether my local devbox, our development server setup, our live servers. It occurred on an obscure server used only as a repository of uploaded files, and it had never seen a .NET application before.
I ended up install VS2022 on it to debug the situation, to some extent I'm glad the VS2022 setup didn't magically "fix" the problem.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
