In this Post we will be looking at how to use methods in PowerShell. When thinking about methods parameters are bound to come up. In C# parameters do not get much glory. But in PowerShell parameters do come with some extra features. Which can be reused when invoking a script from the command line.
In the previous posts we saw how to get setup and in Part 2 how to the basic command structures can be implemented. In this post I’ll assume you are familiar with the topics of those posts. So if you are new to PowerShell you might want to read the posts to get familiar with some basic concepts.
Methods and Parameters
Though PowerShell does not require any methods from the get go. It does provide the structure to make code reusable by putting it into a function.
The C# function above could be translated to a PowerShell as follows.
Most functions take parameters, so let’s do that, again leading of with the C# function:
And the corresponding PowerShell code:
As you can see the PowerShell function uses a special keyword. The parameter name starts with a dollar sign. Type Information is also added to the parameter. It is optional to define the type and if not wanted can be simply left out. Invoking the function does not require any braces for the parameter and they will default to the order they are defined in the method. Now let's look at the following code:
Parameters in PowerShell provide some interesting ways. The previous samples shows how we can write a method with multiple parameters. And also how we can set a parameter by it's name. But we are only scratching the surface of what is possible. The common scenario to start a PowerShell script is from the Command Line Interface (CLI). To keep a script flexible it makes sense to start it with parameters e.g. IP or URI of a server. When defining the same construct as in the method we can have a script requiring parameters.
The script can then be invoked further as follows:
Note that the name of the parameter is reused for the command line parameter. But we can do even more, lets consider the following method description:
We now have three parameters which are assigned default values similar to the way they are done in C#. We can further set the order of the parameters, make a parameter mandatory and even checking a parameter as follows.
Summing it you can see that PowerShell provides a way to work with methods and provides a rich way on interacting with parameters. The parameters can also be used when writing a script. Simply place the parameter code at the top of the script and the parameters can be set when invoking the script.
No introduction on PowerShell would not be complete if we wouldn’t have a small section regarding file handling. Writing to a File is as easy as writing the following line:
This way we can easily persist information for later usage or inspection of a state during runtime. If the goal is to persist the state of a PowerShell object model. Serialization will serve as a better alternative. Serializing an object provides the option of restoring it’s state at a later time. Allowing to inspect the object in the REPL of PowerShell and analyze why a certain condition may have lead to a failure. Serializing an object in PowerShell can be realized with the following command:
Deserializing an object will be performed with the following line:
Storing state by serializing objects into an XML file can provide as an elegant solution for transferring state between machines or rolling back to a previous state if an error occurs during the execution of a script. One could also use the serialized objects for automated tests without having to touch the actual system. Let this be my next blog post relating to PowerShell.
In this post we saw how basic control structures can be created with PowerShell such as:
- Methods and Parameters
- File handling
- Serializing and deserializing objects
With these basic control structures you are able to create simple scripts and reuse code by defining methods. As PowerShell scripts start to grow, testing them gets more and more difficult. This is why in the next post we will be looking into automated testing with PowerShell.