One thing I’ve missed during the past couple of years with virtual-only conferences is the hallway track. While at the PowerShell + DevOps Global Summit 2022, there was a discussion about using PascalCase for parameter names and camelCase for user-defined variables in your PowerShell functions. Specifying different casings depending on the usage seems like a great idea. Determining where you defined your variables would be self-explanatory. The only problem is you need something to verify that you’ve specified them in the correct case.

I recently needed to determine the PowerShell commands and parameters used in multiple scripts. What better way to accomplish this task than to use the Abstract Syntax Tree (AST)? The Get-MrSyntax function begins by requiring at least PowerShell version 3.0. This is the oldest version that exposes the AST. The Path parameter uses ValidateScript for parameter validation to only accept files with a PS1 or PSM1 extension. The path(s) to the script files can be specified via pipeline or parameter input.

Earlier this week, Chris Gardner presented a session on Managing dependencies in PowerShell for the Mississippi PowerShell User Group. I mentioned that I had written a function to retrieve PowerShell module dependencies that’s part of my ModuleBuildTools module. Get-MrAST is one of the primary functions that numerous other functions in the module are built on. #Requires -Version 3.0 function Get-MrAst { <# .SYNOPSISExplores the Abstract Syntax Tree (AST). .DESCRIPTIONGet-MrAST is an advanced function that provides a mechanism for exploring the Abstract Syntax Tree (AST).

As many of you know, I’ve been working on some module building tools. One of the things I needed was to retrieve a list of PowerShell modules that each function required (a list of dependencies). This seemed simple enough through PowerShell’s AST (Abstract Syntax Tree) as shown in the following example. $File = 'U:\GitHub\PowerShell\MrToolkit\Public\Find-MrModuleUpdate.ps1' $AST = [System.Management.Automation.Language.Parser]::ParseFile($File, [ref]$null, [ref]$null) $AST.ScriptRequirements.RequiredModules.Name The modules that are retrieved by the AST are simply the ones specified in a functions Requires statement.

As I previously mentioned a little over a month ago in my blog article PowerShell Script Module Design Philosophy, I’m transitioning my module build process to a non-monolithic design in development and a monolithic design for production to take advantage of the best of both worlds. Be sure to read the previously referenced blog article for more details on the subject. My goal is to write a reusable tool to retrieve the necessary information from a non-monolithic script module that’s necessary to create a monolithic version of the same module.

This blog article is the third in a series of learning about the PowerShell Abstract Syntax Tree (AST). Be sure to read the other two if you haven’t already. Learning about the PowerShell Abstract Syntax Tree (AST) Learn about the PowerShell Abstract Syntax Tree (AST) – Part 2 Learn about the PowerShell Abstract Syntax Tree (AST) – Part 3 In this blog article, I’ll be specifically focusing on finding the AST recursively.

In my previous blog article a few weeks ago on Learning about the PowerShell Abstract Syntax Tree (AST), I mentioned there was an easier way to retrieve the AST so that you didn’t have to cast everything to a script block. There are two .NET static methods, ParseFile and ParseInput, that are part of the Parser Class in the System.Management.Automation.Language namespace which can be used to retrieve the AST. First, I’ll store the content of one of my functions in a variable.

This week, I’ll continue where I left off in my previous blog article PowerShell Script Module Design Philosophy. Moving forward, the development versions of my PowerShell script modules will use a non-monolithic design where each function is dot-sourced from the PSM1 file. When I move them to production, I’ll convert them to using a monolithic design where all functions reside in the PSM1 file. In development, each PS1 file uses a Requires statement which specifies the requirements from a PowerShell version and required modules standpoint.