Set up a PowerShell and .NET Development Environment with AWS Cloud9 and Amazon EC2

Background Amazon Web Services (AWS) Cloud9 provides a cloud-based Integrated Development Environment (IDE) where you can author, test, and deploy your .NET Core and PowerShell-based applications. You can connect to your Cloud9 IDE using a web browser. One of my favorite features offered by Cloud9, that enables developers to comfortably use it, is the support … Read moreSet up a PowerShell and .NET Development Environment with AWS Cloud9 and Amazon EC2

Use PowerShell to Persist Environment Variables

Persistent Environment Variables PowerShell

In PowerShell, you can easily create environment variables using a few different methods. However, these are only scoped to the current PowerShell process, and not to any process running inside the user’s profile, or any process running on the system. Here are a few examples of methods that you can use to set environment variables … Read moreUse PowerShell to Persist Environment Variables

Writing Interactive Scripts with PowerShell

If you’re authoring PowerShell scripts that are intended to be interactive, there are a couple of very easy ways to ask your users for input. Typically, user input falls into a couple categories: free-form text input, or a list of pre-defined values. We also might need to prompt the user to type in a secure … Read moreWriting Interactive Scripts with PowerShell

Implementing a .NET Class in PowerShell v5


You might have heard that PowerShell version 5.0 has introduced support for building .NET classes. Indeed, this is a powerful, new capability that has not previously existed in native PowerShell syntax. Before the new class-building syntax existed, if you wanted to build custom objects in PowerShell, you generally would either: 1) use the [PSCustomObject] type, or 2) build a .NET class in C#, and use the Add-Type command to import it into the PowerShell session.

Read moreImplementing a .NET Class in PowerShell v5

Automating the Lync Client with PowerShell

You love PowerShell, right? And you love the Microsoft .NET Framework? Are you setting out to automate the Microsoft Office 2013 Lync Client with PowerShell? If you answered “yes” to the last three questions, then you’ve come to the right place! We’re going to take a look at how to get started automating the Lync 2013 client using PowerShell! Thanks to PowerShell’s direct support for Microsoft .NET Framework types, we can easily manage Lync Client functions from PowerShell, much in the way that C# developers can!

Download and Install the SDK

The first thing you need to do is go out to Microsoft’s download site and grab the Lync 2013 SDK. The installation process is fairly painless, so just click “Next” through it. By default, the installation path is: %ProgramFiles(x86)%\Microsoft Office\Office15\LyncSDK.

Figure: The root folder of the Lync 2013 SDK.
The root folder of the Lync 2013 SDK.

When you install the Microsoft Lync 2013 SDK, what you get is basically a series of Microsoft .NET assemblies (aka. .NET libraries) that allow you to perform automation functions on the Lync 2013 Client! Additionally, there is a CHM (compiled HTML help) file that contains some detailed documentation on how to utilize the SDK. If you’re interested in developing, get used to reading documentation!

Read moreAutomating the Lync Client with PowerShell

PowerShell: Embed binary data in your script

When writing automation scripts or modules, you might find that you frequently reference external binary data.

Binary data? Well, that accounts for all data!” you might say.

Yes, that’s true. But I’m talking about binary data as opposed to files containing simple ASCII or UTF-8 data. Maybe there’s some better terminology to describe that, but hey it works for now. Binary data could include things such as:

  • Word documents
  • Executable (Portable Executable format)
  • Code libraries (DLLs)
  • Registry files
  • etc.

In the case of executables, oftentimes they provide useful functionality that would take many lines of PowerShell code to replicate. Some developers, for better or for worse, elect to use these utilities instead of going through the effort of writing the necessary code to handle the function natively in PowerShell. This creates an additional dependency when porting the PowerShell code, as the author must be sure to include the utility with their code, or otherwise ensure (via documentation, for example) that the target user will already have it available.

Wouldn’t it be nice if you didn’t have to depend on the user having some executable pre-installed, just to get your script to work, though? Unfortunately the little topic of “software licensing” can sometimes prevent redistribution of software that you are not given explicit permission to copy, however there are also many cases where this is allowed (eg. open-source projects). The work-around in cases where redistribution is not allowed, is to either direct the user where to download the software from, or automate it for them.

Read morePowerShell: Embed binary data in your script

PowerShell: Tracert or Trace-Route?

UPDATE (2012-07-27): Justin Dearing (@zippy1981) sent me an updated version of the script, which improves on the following:

  • Has some comment-based help
  • Parameter checking

Grab it here: Invoke-TraceRoute.ps1

Any network or systems administrator is familiar with the good old tracert.exe utility that’s been included outof-the-box in Windows for years now. Tracert allows you to identify each “hop” (typically a router) between two IP endpoints on a network. Since this utility was developed long before PowerShell existed, and has been time-tested, it hasn’t been implemented yet as a PowerShell cmdlet. That being said, PowerShell folks often do not enjoy reliance on external dependencies, and prefer the flexibility of an API that can provide only the information that they want or need. To that end, I have developed a Trace-Route PowerShell advanced function (cmdlet) that emulates a limited set of functionality offered by tracert.exe.

Read morePowerShell: Tracert or Trace-Route?

PowerShell: Twitter Folks

Hey folks, here are some of the top tweeters on the topic of PowerShell! All of them come with my strong recommendation to follow them! You will be in good company, and will probably learn a LOT, if you keep in touch with these ridiculously smart folks.

Jeffrey Snover –

Don Jones –

Jon Walz –

Hal Rottenbeg –

Doug Finke –

Boe Prox –

Adam Driscoll –

Ravikanth Chaganti –

Read morePowerShell: Twitter Folks

PowerShell: List Strongly Typed Names in Global Assembly Cache

I dislike using deprecated commands or APIs when I know that there’s a more modern method of performing an action. I also generally prefer to use Windows PowerShell as a .NET scripting language, rather than constantly relying on cmdlets. To be sure, I use a balance of both concepts, since cmdlets can save a whole lot of coding a lot of the time.

Every time I want to load an assembly into PowerShell, the first thing that pops into my mind is using the LoadWithPartialName() method:
[cc lang=”powershell”][Reflection.Assembly]::LoadWithPartialName();[/cc]
Unfortunately Microsoft recommends against using that static method, as it is deprecated, and recommends use of other methods such as LoadFile() or Load() like:
[cc lang=”powershell”][Reflection.Assembly]::Load(StronglyTypedAssemblyName);[/cc]
In the interest of not breaking my conscience, I would like to use this method, but the problem then becomes that I have to constantly figure out what the strongly-typed name of the assembly I want is. To help solve this problem, I decided to write a PowerShell script that extracts information from the .NET assemblies in the Global Assembly Cache (GAC), since those are generally the most common ones I’ll need to reference.

Read morePowerShell: List Strongly Typed Names in Global Assembly Cache

PowerShell: Shortening Web Service Type Names with a Hashtable

When you use the New-WebServiceProxy class, you probably have noticed that PowerShell dynamically generates some really ugly type names. For example, if we get a reference to the Bing web service (you’ll need to get an API key first):

$BingSearch = New-WebServiceProxy -Class BingSearch -Uri "$ApiKey"

… and examine the types contained within it:

$BingSearch.GetType().Assembly.GetExportedTypes() | select FullName

… you’ll notice some ridiculously long type names based on your API key, such as:


Read morePowerShell: Shortening Web Service Type Names with a Hashtable