SAPIEN Information Center
Over the years, the articles in our blog have grown extensively. There's a lot of valuable information in there, but it's become hard to find because it's mixed in with various tour announcements, special offers, conference recaps and the like. So, we decided to pull the important articles and place them here—along with information we find relevant to PowerShell and scripting—in a more organized and easily searchable venue.
We are constantly adding to this cornucopia of material about SAPIEN Technologies, Inc. products, PowerShell, and things you never knew you needed to know. So make this a place you frequent often for tips, tricks, advice and plain old 'how-tos'.
Whether it is your first visit here or your 100th, we are sure you will find something useful. Enjoy!
Installing PowerShell 6 -- For Everyone
I've been having a great time exploring the new open-source, cross-platform version of PowerShell core on my Windows PC and on my Mac (yes, I have a MacBook Air!). When I mention this to folks, they give me that crinkled look. Either they're very busy, and I understand, or they assume that open-source PowerShell is for developers. It's written in C#, it needs to be compiled and built, and it's in GitHub, which really isn't for everyone.
But, no! PowerShell 6 (officially, PowerShell 6-alpha) is for everyone! Even if you're not a developer, you can download and install it, play with it, and update it very easily. You don't need to mess with GitHub. You don't need to learn C#. You don't need to install Visual Studio. You don't need to build or compile anything.
Working with SemanticVersion in PowerShell
As the versions of Windows PowerShell and PowerShell (not only Windows!) proliferate, it becomes more important to know on which version of PowerShell your shared scripts and modules are running.
Beginning in the open-source versions of PowerShell 6.0-alpha, the version object in $PSVersionTable.PSVersion switched from a System.Version object to a System.Management.Automation.SemanticVersion object.
Requiring a Version of PowerShell
I just returned from the second annual PowerShell Conference Asia 2016 (@PSConfAsia) in Singapore and it was a blast. Like all of the best conferences, it was small and designed for learning and interaction, not focused on huge auditoriums and collecting swag. It had a top-notch panel of speakers including four PowerShell Team members and representatives from AWS, Chef, and Puppet.
But, for me, the best part was the attendees. This was an audience that we don't often meet in person, because it's tough and expensive for folks from South Asia, Southeast Asia, Australia, and NZ to travel to the U.S. or Europe. It was really a pleasure. The attendees were smart and knowledgeable, participated in every activity, asked great questions, and engaged in fascinating discussions. SAPIEN Technologies, Inc, a founding sponsor of PSConfAsia, was so honored to sponsor this conference again.
June Blender and friends at PowerShell Conference Asia 2016.
Photo by @Campus Lead for NYP Microsoft Student Partners (Singapore)
This blog post is taken from my Avoiding Version Chaos in a Multi-Version World talk, which I first delivered for the Mississippi PowerShell User Group in January 2016, but revised substantially to include PowerShell 6.0.0-alpha. I'll start with the basics of #Requires -Version and continue in a follow-up post about the new SemanticVersion object that PowerShell uses in PowerShell 6.0.0-alpha.
What does #Require -Version Require?
The standard and official way to require a particular version of Windows PowerShell is the #Requires -Version directive. Help says that a #Requires directive works only in a script (not interactively) and must be the first line of code in the script (after comments). In reality, you can put other lines of code before #Requires, but PowerShell runs the #Requires first, and then runs any commands that precede it.