That's exactly why I use it. Only dev environment available to me.

Windows ships with VBScript, JScript, CMD, C#, and PowerShell right out of the box. I recall interviewing a college guy around 2018, and he tried to educate me about how Windows doesn't have a good command line / scripting / automation solution beyond command.com. I think I still said "hire" because he had other talents, but damn.

Windows doesn't ship with C# out of the box. It ships with the runtime for .NET Framework 4.8, but not with the SDK.

I'm not much of a PowerShell wiz so apologies if this is hideous, but I stuck this in my profile.ps1 a few years ago:

  $Csc = gci "$env:windir\Microsoft.NET\Framework64\*\csc.exe" -ea silent | select -last 1
  if ($Csc) {
    Set-Alias -Name csc -Value $Csc
    $Csc = $null
  }

It makes the csc that comes with .NET available out of the box on pretty much any Windows system. I'm not sure how good it is at building serious programs, but it's good enough for little static void Main thingys. I doubt it's useful for the same demographic that would be using VBA, though.

  if ($Csc = gci "$env:windir\Microsoft.NET\Framework64\*\csc.exe" -ea silent | select -last 1) {
    Set-Alias -Name csc -Value $Csc
    Remove-Variable Csc
  }

Or even:

  gci "$env:windir\Microsoft.NET\Framework64\*\csc.exe" -ea silent | % {
    Set-Alias -Name csc -Value $_
  }

As I understand it, PowerShell allows you, out of the box, to write some C# code in a string, and then run it. And by C# code I mean regular classes with all the bells and whistles.

*wink*

    $code = @'
    using System;
    using System.Drawing;
    using System.Runtime.InteropServices;
    using Microsoft.Win32;


    namespace Background 
    {
        public class Setter {
            [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
            private static extern int SystemParametersInfo(int uAction, int uParm, string lpvParam, int fuWinIni);
            [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError =true)]
            private static extern int SetSysColors(int cElements, int[] lpaElements, int[] lpRgbValues);
            public const int UpdateIniFile = 0x01;
            public const int SendWinIniChange = 0x02;
            public const int SetDesktopBackground = 0x0014;
            public const int COLOR_DESKTOP = 1;
            public int[] first = {COLOR_DESKTOP};

            public static void RemoveWallPaper() {
            SystemParametersInfo( SetDesktopBackground, 0, "", SendWinIniChange | UpdateIniFile );
            RegistryKey key = Registry.CurrentUser.OpenSubKey("Control Panel\\Desktop", true);
            key.SetValue(@"WallPaper", 0);
            key.Close();
            }

            public static void SetBackground(byte r, byte g, byte b) {
                RemoveWallPaper();
                System.Drawing.Color color= System.Drawing.Color.FromArgb(r,g,b);
                int[] elements = {COLOR_DESKTOP};
                int[] colors = { System.Drawing.ColorTranslator.ToWin32(color) }; 
                SetSysColors(elements.Length, elements, colors);
                RegistryKey key = Registry.CurrentUser.OpenSubKey("Control Panel\\Colors", true);
                key.SetValue(@"Background", string.Format("{0} {1} {2}", color.R, color.G, color.B));
                key.Close();
            }
        }
    }
    '@

    $null = Add-Type -TypeDefinition $code -ReferencedAssemblies System.Drawing.dll -PassThru

    Function Set-OSDesktopColor {
    param (
        $r,$g,$b
        )

        $null = [Background.Setter]::SetBackground($r,$g,$b)

        }

I think it does since the Windows XP days, at least a CLI based compiler/interpreter.

Would you look at that, it does!

C:\Windows\Microsoft.NET\Framework64\ has both MSBuild.exe and csc.exe, but only for .NET Framework up to 4.0. I was under the impression that 4.8 was installed on Win 10 machines via Windows Update.

PowerShell including ISE, with tabs, multi-line cursor, syntax highlighting, autocomplete, step-through debugger, snippets, scriptable/extensible.

And yet if you send your PS script to say an HR person… it won’t run on their computer without messing with security settings.

Nobody on the team wanted that, not even Snover, but we were making that thing in about 2005, when everyone was getting burned by email based zero days. Even though we had the Set-ExecutionPolicy thing there were boogeyman news articles immediately after the v1 release asking whether the new scripting language was...too powerful.

PowerShell with ISE is a lot better than the VBA editor in many ways but you're still in the same situation of using a long deprecated ide with an ancient version of a programming language (ISE is deprecated and if you're using the built in version of PowerShell you're stuck on the last legacy framework version from 7 years ago forever and missing a ton of improvements and fixes from newer versions of powershell)

Today, yes, but ISE has shipped with Windows since what, XP? And VBA never has - it's a part of Office.

So disappointed that MS hasn't rolled out PowerShell 7 but I guess it's easier to develop a programming language when you don't have to deal with users.

People think I am nuts for preferring the ISE over VSCode, but the ISE never crashes while running scripts!

You're not, I would also rather have the Powershell team improve ISE than their decision to migrate into VSCode, but alas.

Then you haven't used it enough :) The bare shell on the other hand is usually solid.

That's for sure not true. For my bigger projects (over 200 lines), I tend to use VSCode. Just having a look at the larger projects I've got up on github, I'm over 2000 lines across 3 projects - all developed in Code.

ISE does occasionally hang / crash, but it's quite rare compared to how VSCode behaves across every machine I've used it with. It really seems to be just a Powershell problem, haven't had the same issue in any other language.

When I'm really making great progress on something, having to fart around with killing and restarting the shell constantly is really disruptive. Yes, Code has better and more features, but for me the extra productivity does not overcome the crashy shell.

I think you might be misunderstanding what I didn't say - I use the console for debugging (Set-PsDebug!) and even then it crashes (sometimes.)

I don't like vscode for powershell development and I find the pycharm experience for powershell (lol) much better.

VBScript is deprecated: https://nolongerset.com/vbscript-deprecation/

JScript is deprecated, and is likely to be removed at some point too...

CMD is often blocked on many people's machines due to group policy.

PowerShell is really the only other option other than VBA, as discussed in the article. Only reason I haven't used PowerShell til now is the version was hidiously outdated and didn't even support classes... Of course with PowerShell you can evaluate C# code.