PowerShell 5 brought class based DSC Resources, which majorly simplifies the process of writing custom DSC resources. During my time working on some custom resources, I developed some tips a long the way which should save you some time and pain during your DSC journey. The tips cover:
Structuring your class based DSC Resources
Making it easier to get IntelliSense based on your DSC resources without constantly copying them into the module path
Using PowerShell ISE IntelliSense when writing DSC configuration
Troubleshooting resources which aren’t being exposed correctly from your DSC Module
By the time you are using PowerShell to automate an increasing amount of your system administration, database maintenance, or application-lifecycle work, you will likely come to the realization that PowerShell is indeed a first-class programming language and, as such, you need to treat it as such. That is, you need to do development in PowerShell just as you would with other languages, and in particular to increase robustness and decrease maintenance cost with unit tests and–dare I say–test-driven development (TDD). I put together several articles on getting started with unit tests and TDD in PowerShell using Pester, the leading test framework for PowerShell. This series introduces you to Pester and provides what I like to call “tips from the trenches” on using it most effectively, along with a gentle prodding towards a TDD style. Part 1: Getting Started with the Pester Framework Starting with the ubiquitous “Hello, World”, this introduces Pester, showing how to execute tests, how to start writing tests, and the anatomy of a test. Part 2: Mock Objects and Parameterized Test Cases To be able to create true unit tests, you need to be able to isolate your functions and modules to be able to focus on the component under test; mocks provide great support for doing that. Another topic of “power” unit tests is making them parameterizable, i.e. being able to run several scenarios through a single test simply by providing different inputs. Part 3: Validating Data and Call History The final part of this series provides a “how-to” for several other key parts of Pester: how to validate data, how to determine if something was called appropriately, and how to address a particular challenge with Pester, validating arrays. I’ve included a library for array validation to supplement Pester. For a more general treatment of unit tests, I refer you to Roy Osherove’s canonical text on the subject, The Art of Unit Testing.
Long has it been known how to easily document your PowerShell source code simply by embedding properly formatted documentation comments right along side your code, making maintenance relatively painless…
But if you advanced to writing your PowerShell cmdlets in C#, you have largely been on your own, either hand-crafting MAML files or using targeted MAML editors far removed from your source code. But not anymore. With the advent of Chris Lambrou’s open-source XmlDoc2CmdletDoc, the world has been righted upon its axis once more: it allows instrumenting your C# source with doc-comments just like any other C# source: All of the above provides fuel for Get-Help, i.e. providing help one cmdlet at a time. But we are a civilized people; we also need a web-based version of our full custom PowerShell API. That is, a hierarchical and indexed set of Get-Help pages for all the cmdlets in our module. For this task, my own open-source effort, DocTreeGenerator, nicely fills the gap, requiring very little beyond the doc-comments described above to do the complete job. I have written extensively on using both XmlDoc2CmdletDoc and DocTreeGenerator, and just this week, released a one-page wallchart that shows how all the pieces work together: Here’s the link to get you started on this fun journey: Unified Approach to Generating Documentation for PowerShell Cmdlets
After authoring last month scripting games puzzle, which involved some scripting around the Unicode standard, I decided to have some fun and write a PowerShell module which interacts directly with the online Unicode Database (UCD) to retrieve the main properties of characters.
Using this module you will be able to retrieve the following information for a single char or for every char in a given string:
Glyph name
General category
Unicode script
Unicode block
Unicode version (or age)
Decimal value
Hex value Here’s a few sample outputs you can get from using the functions in the UnicodeInfo module:
Get-Unicodeinfo '$' Glyph : $ Decimal value : 36 Hexadecimal value : U+0024 General Category : CurrencySymbol Unicode name : DOLLAR SIGN Unicode script : Common Unicode block : BasicLatin Unicode version : 1.1Get-Unicodeinfo ‘Powershell!’ | Format-Table
Glyph Decimal value Hexadecimal value General Category Unicode name Unicode script Unicode block Unicode
version
There is a lot of documentation out there for interacting with Microsoft Office including Outlook, Excel, Word, etc with Visual Basic for Applications (VBA). A lot of time you may only be able to find VBA examples. VBA’s require template files to be sent to the desktop and are a real hassle when trying to automate across multiple machines. There are not many A to B examples of translating VBA to PowerShell so I took a problem I had solved in the past and presented the before and after. Hopefully it will provide enough information to allow others to convert VBA code into PowerShell for their scenarios. You can check out the full article on PowerShellBlogger.com.
If you are not on Office 365 or have a tenant set up with Microsoft yet, now is the time to reserve your tenant name! With utilizing Office 365, a lot of administration is only available from a PowerShell session. There is a mix of outdated information on what you actually need to install and execute in order to connect to all of the Office 365 services. As a result, I accumulated and wrote up the current download requirements and commands to connect and administer every Office 365 service from one PowerShell session. I hope this saves everyone a lot of time and effort! Head over to PowerShellBlogger.com to read the full article here.
ChatOps is a term used to describe bringing development or operations work that is already happening in the background into a common chat room. It involves having everyone in the team in a single chat room, then bringing tools into the room so everyone can automate, collaborate and see how automation is used to solve problems. In doing so, you are unifying the communication about what work gets done and have a history of it happening. ChatOps can be supplemented with the use of tools or scripts exposed using a chat bot. Users in the chat room can talk to the bot and have it take actions on their behalf, some examples of this may be:
Creating windows shortcuts are usually done through the New Shortcut Wizard, MSI files, Group Policy Objects, or even a simple file copy. Shortcut files are .lnk files that Microsoft Windows uses for shortcuts to local files while .url is used for destinations such as web sites. As we all are aware, the .lnk filename extension is hidden in Windows Explorer even when “Hide extensions for known file types” is unchecked in File Type options. The reason for this is the NeverShowExt string value in HKEY_CLASSES_ROOT\lnkfile. Shortcuts are also displayed with a curled arrow overlay icon. The IsShortcut string value causes the arrow to be displayed. For a full run down on creating shortcuts and favorites with PowerShell head over to PowerShellBlogger.com.
When you are wanting to run code remotely, it’s common to do this via the use of Invoke-Command (though other options exist, such as through Start-Job for example). The biggest downfall to date i’ve found with remoting is the lack of an option to combine the use of your local functions within a ScriptBlock that has other code in it. As an example, the following is not possible:
function Add ($param1, $param2) { $param1 + $param2 } function Multiply($param1,$param2) { $param1 * $param2 } Invoke-Command -ComputerName $env:COMPUTERNAME -ScriptBlock { $addResult = Add $args[0] $args[1] $multiplyResult = Multiply $args[0] $args[1] Write-Output "The result of the addition was : $addResult" Write-Output "The result of the multiplication was : $multiplyResult" } -ArgumentList 3, 2 However, there is a way to achieve this type of operation, and make as many local functions as you want available to be used and combined with other code in your ScriptBlock. You can find the full article at powershell.amsterdam.
Thanks to all those who participated in the PowerShell Editor Services Hack Week last week! Much progress was made on fixing bugs and adding new features to both PowerShell Editor Services and the PowerShell extension for Visual Studio Code. Here’s a quick summary of the contributions that were made during the week: Variable Display Improvements in the Debugger Keith Hill made many great improvements to how we display variable contents in the Visual Studio Code debugger. First of all, he added support for variable scopes other than just “Local” as we had before. You can now inspect variables from both the Global and Script scopes. You will also see a special “Auto” section which filters the set of variables down to those that were defined in the current scope. This is really helpful for quickly checking the state of the variables in your functions! He also added greatly improved the variable value display for collections such as arrays and dictionaries and also objects which implement the ToString() method in .NET. You will now see much greater detail for these variables in the debugger: New Expand Aliases Command Doug Finke contributed a new “Expand Aliases” command which searches your script file or selection for the use of cmdlet aliases. For any alias it finds, it replaces the text with the full command name. This is helpful for developers who want to quickly write out scripts using aliases but resolve them to their command names before committing to source control. Here’s a GIF of the feature in action (click to play!): Sublime Text Editor Integration Work on the integration of PowerShell Editor Services in Sublime Text has progressed quite well this week. The basic protocol implementation is now working, enabling language features to be integrated over time. I’ve also implemented basic file management support so that opened files are sent to Editor Services for syntax checking and semantic analysis. From this point it’s just a matter of integrating the language features of PowerShell Editor Services into Sublime’s UI using its plugin API. Check out the current code in the editor-services branch of my fork of the PowerShell Sublime Text package. Once this effort is stable enough for an initial release, I’ll be submitting a PR back to the original PowerShell Sublime Text package repo and future work will continue there. Atom Editor Integration Some work was started on an integration with the Atom editor but it was quickly determine that Atom’s APIs for language features were to sparse to make quick progress. However, with the experience gained from the Sublime Text integration, future work on the Atom integration should be much easier. Expect to see more effort in this area in the first half of 2016. Miscellaneous Improvements
