Book Image

Windows PowerShell for .NET Developers - Second Edition - Second Edition

Book Image

Windows PowerShell for .NET Developers - Second Edition - Second Edition

Overview of this book

Windows PowerShell 5.0 for .NET Developers is your self-start guide to performing automation using Windows PowerShell. This book will help you to understand the PowerShell syntax and grammar and will also teach you techniques to remove the rough edges of manual deployments. Packed with PowerShell scripts and sample C# codes to automate tasks, it also includes real-world scenarios such as administrating office servers to help you save time and perform deployments swiftly and efficiently. The book begins with the Windows PowerShell basics, explores the significant features of Windows Management Framework 5.0, covers the basic concepts of Desired State Configuration and the importance of idempotent deployments. By the end of the book, you will have a good understanding of Windows PowerShell’s features and will be able to automate your tasks and manage configuration effectively.
Table of Contents (13 chapters)

Understanding PowerShell modules


Windows PowerShell modules present a simple way to organize and package our script so as to make it distributable and reusable.

In this section, we will cover the following topics:

  • What is a module?

  • Script modules

  • Binary modules

  • Manifest modules

  • Dynamic modules

Introduction to modules

Windows PowerShell can be created dynamically or persisted to our disk. While discussing PowerShell modules, for a moment I thought about the old-style snap-ins in PowerShell version 1.0, which still exist. Yeah! SharePoint still has snap-ins and not modules.

Snap-ins only contain cmdlets and providers, whereas in modules, we can have functions, variables, aliases, and PowerShell drives.

Before we create a module, we need to know what a module should deliver and where it should be placed. Use this code to find the module path:

$env:PSModulePath -split ';'

You will see two different paths, where one is the system location and the other is the user profile location, as follows:

$ENV:Windir...