Create your own Powershell module and cmdlet

In this blog, let us see how we can create a module and cmdlets inside it. We will be using Powershell ISE(Administrator) to do this.

First, we will create a cmdlet and then a module.

Create a cmdlet

1) Prepare the script which you want to expose as a cmdlet. For demo purpose, I will use the following.


2) Switch to Script mode(Ctrl+R) and save this script with an extension .ps1


3) Parameterize out the things that might change by using the keyword param.

4) Switch to the console mode(Ctrl+R) and check the help content that is being built for this file.

5) It is showing that our parameter searchTerm is a generic Object type. Suppose, we want it to be a string. We can do it like this.

Now, the Get-Help shows the expected type as a string.

6) We can also decorate our script with CmdletBinding attribute as shown. This gives us extra built-in functionalities like Verbose, Debug etc.



7) To provide properly formatted and additional help for our cmdlet, we can add our inputs in comments on top of the cmdlet. Whatever we mention in the synopsis will be displayed in synopsis section of Get-Help and likewise.


8) Now, except the additional help section, we can enclose the whole thing inside a Function with a name having format Verb-Noun, here Get-MyProcesses.


We also have a template for cmdlets. On the script tab, just press Ctrl+J and select the cmdlet option and get the following.


So, now, we have successfully created our cmdlet. How do we use it?
We can use it by importing the .ps1 file and calling the Get-MyProcesses cmdlet.


We would like to make it more standardised so that we can package our cmdlets inside a module and share it with others.

Create a Module

1) Now, just do a Save-As on the script file that you created. Save it with .psm1 extension. This is our module.

2) We can get all the Module paths in Powershell using the following command. We should deploy our module in the first path i.e. one which is specific to the logged-in user.

3) We need to create this path if it's not already there. Also, we need to have a folder inside Modules folder with name same as the script file name(here, MyScript).

4) Now, copy the package(.psm1) from where you created it to this location.

5) That's all. Now, our module and the associated cmdlets are ready for use.



Hope this helps!

NuGet - Create, Host and Reference a package

Yesterday, for the first time, I came across a scenario where I had to reference and build the project using a NuGet package exposed from a local or shared path.

I faced few issues while trying to do this. Let's walk through the process in this blog.
This setup involves following three steps:-

1. Create a NuGet package. Usually, we consume packages already created by some third-party, but here, I want to demonstrate the creation of NuGet packages also.

2. Host the NuGet package

• As official NuGet feeds library 
• As local feeds.

3. Reference the NuGet package in the client application.

1. Create a NuGet package:-

For this blog, I created a simple Class Library with the following function in it.

Then, I created the DLL in Release mode.

Now, I opened Package Manager Console from the following path in Visual Studio.

Tools -> NuGet Package Manager -> Package Manager Console.

Check the Package Source and Default Project selected in the Package Manager Console. By default, the location for package source will be nuget.org and your current project as the default project. 

You can check the packages installed for your project by using Get-Package cmdlet in the Package Manager Console. Initially, my class library did not have any packages installed on it. 

Now, I executed the command to create the nuspec file and got the following error.

nuget spec HelloWorld.dll

After some searching, I found that I was missing the NuGet command-line package. So, I installed that.

install-package nuget.commandline

Then, I was able to create the nuspec file.

nuget spec HelloWorld.dll

After that, I had to edit the nuspec file with all the relevant details viz. id, version, title, author etc.

Then, I had to create the package using the following command.

nuget pack HelloWorld.nuspec

See all those warnings?! Like a true developer, I didn't even bother reading those warnings as soon as I saw that "Successfully created package" message ;) 

But, we'll see how I had to redo the whole process due to this mistake.

2. Host the NuGet package:-

We can host our NuGet packages in the following two ways:-

i) As official NuGet feeds library - For this, we need to sign up on nuget.org and get an API key. After this, we just need to upload our package on this website using the API key and that's it. We can search the package up in the Client application and use it.

ii) As local feeds - We need to place the package in some path and go to the Package Manager Settings from the Package Manager Console. Here, we need to add another source path from where we can get NuGet packages as shown below.

3. Reference our new NuGet package in the client application:-

Let's create a new simple console application to consume our new package now.

Using the Package Manager Console, change the source of packages from nuget.org(default) to HelloWorld Package. It will show us our new package.

Now, we need to install this package. I tried doing that but got the following error.

This is where overlooking those warnings(like a true developer) came back to haunt me..!! ;)

Finally after some searching, I got this link which tells about the convention that we need to follow in order to build a proper package.

To check the contents of any nupkg file, you can use NuGet Package Explorer. This is something similar to ildasm for a package.

After going through the link, I restructured the folder where I had placed my DLL as shown below. Here, the net45 folder is used as I had built the console app targeting .NET Framework 4.5. More details on the conventions for this folder structure are provided here.

Now, follow the steps from beginning and create the package again. That's all.

After that, referencing the DLL in the new project works like a charm..!! :)

Hope this helps.

Streams in Powershell

We have the following 7 types of streams in Powershell.

1. Write-Output
2. Write-Host
3. Write-Debug
4. Write-Verbose
5. Write-Error
6. Write-Warning
7. Write-Information(introduced in v5.0)

We will take a look at each of them below:-

1. Write-Output - It is used to write the result to the output stream. In the example below, we can see that since the result from first cmdlet is passed to the second cmdlet, the filter condition is applied and "Roshan" is filtered out due to it's length.
2. Write-Host - It sends the output directly to the console. Due to this, it cannot be piped with other cmdlets. Here, in the example below, continuing from the first example, we can see that "Roshan" is displayed on the screen because it is directly written on the console and the filter condition is not applied on it.
3. Write-Debug - It is used to write debug information on the console. By default, the $DebugPreference is set to SilentlyContinue. So, by default the message will not be displayed on the console. If we set the $DebugPreference to Continue, the debug messages will start appearing on the screen.
4. Write-Verbose - This cmdlet is used to provide additional information about the command that is being debugged. Similar to Write-Debug, this cmdlet has $VerbosePreference which needs to be set to Continue for the messages to be displayed on the screen.
5. Write-Error - It writes the result to the Error stream.
6. Write-Warning - It writes a warning message. Similar to Write-Debug and Write-Verbose, it has $WarningPreference which needs to be set to Continue for it to be displayed on the console.
7. Write-Information - It displays additional information about the execution of any script. Depending on the $InformationPreference, it displays those messages during the execution of the scripts.

Hope this gives you a head start on the various available streams in Powershell.