PowerShell Tools for Visual Studio – Now 100% more free!

UPDATE: Just download the Visual Studio 2013 Communtiy edition and PoshTools works perfectly with it!

Recently, the Python Tools for Visual Studio team released support for Visual Studio Express 2013. After emailing the team, I found that there is a white list of extensions that are allowed to be installed in Express. Unfortunately, this is an internal Microsoft process and not available to external developers. Although this was a bummer, they pointed me once again towards the Visual Studio Isolated and Integrated Shell. I had previously experimented with the Isolated Shell with little luck and didn’t pursue it until a nudge from the PyTools team. Rather than having to create an entire Isolated Shell environment, you can instead download and install the Integrated Shell. It provides the entry point to launch the components provided by the Isolated Shell. It certainly was confusing to me but I gave it a shot. Success! You can download and install both the Isolated and Integrated Shells and then install PowerShell Tools for Visual Studio. 100% free!

Installation Steps

1. Download and Install the Isolated Shell
2. Download and Install the Integrated Shell
3. Open Extensions and Updates…
4. Install PowerShell Tools for Visual Studio

Black magic:


So far, it looks like there are a couple features that aren’t working quite correctly.

– Debugging doesn’t seem to work as expected. This really limits the functionality and I’ll be looking into it.
– No built in source control integration. This sucks but is just a limitation of Isolated Shell. There are extensions for Git and SVN available on the gallery.

Otherwise, things stuff as IntelliSense, REPL, Syntax Highlighting and the project system seem to be behaving.

Feel free to try it out and look forward to updates in the near future.

PowerShell Tools – v0.8.0 – Now with REPL!

Today, I’m announcing the release of PowerShell Tools for Visual Studio v0.8.0. There are some important installation changes in this version and I want to make sure people are aware. You can download the latest on the Gallery (2012\2013) or via GitHub.

Installation Changes – Important!

The extension has been broken into two different editions based on Visual Studio version. This was done to fix installation issues caused by how the extension was being built. Building a different version for each version of Visual Studio has corrected this. For Visual Studio 2012 users, you’ll need to uninstall your current version of the extension and install the new version. Installing them side by side will cause issues. This should be the only time you’ll have to do something like this.

REPL Window 

This version adds an interactive REPL window. The REPL window is based on the same REPL that is integrated with the Python and Node tools for Visual Studio. You can run commands just like you would in any other PowerShell command window. You can access the window via View->Other Windows->PowerShell Debug Interactive. Output from your PowerShell scripts now goes to this window rather than the Output pane.


Minor Bug Fixes and Changes

  • Fixed test discovery
  • Removed Project property pages because they were not actually functional
  • Added $DTE variable for StudioShell support and automation accessibility

PowerShell Tools for Visual Studio Thanksgiving Special!

In celebration of the Thanksgiving holiday (and because I finished a bunch of cool stuff), I’ve released a healthy update to PowerShell Tools for Visual Studio to the Gallery! There have been a lot of enhancements to the extension. I’ll highlight some of the key features in this post.

Unit Test Adapter

This particular feature I’m pretty excited about. It exposes Pester support to enable authoring of PowerShell-based unit tests that are discoverable and executable via the Test Explorer window. The adapter picks up on Describe blocks and allows you to execute them as a set or individually. When a test fails, the stacktrace and error message are presented in Test Explorer. This should also allow you to run your unit tests during CI builds in TFS. Pester support requires Pester to be installed on the module path. PoshTools does not include it at this time.



Data Tips and Watch Window 

One feature I love in Visual Studio is the ability to hover over a variable and see it’s value. The newest version of PoshTools now has this functionality! It supports arrays and hashtables (unlike some of the interim GitHub releases). It expands multiple levels; just like other managed languages.



In addition to hovering, you can specify variables in the watch window. Handy!



Dark Theme Support

The last time I promised dark theme support, it was a lie (like the cake). I had implemented it incorrectly. This version now correctly supports the dark theme. If you are still having problems with the dark theme after an upgrade, make sure to reset your colors to default for the dark theme. The colors for the dark theme aren’t as vibrant as they were (if it worked for you) but they correctly change when themes are switched. You can still update your own colors for the theme.




I’ve also added support for Read-Host. You’ll get this handy dandy input box to specify anything you desire!


As always, this release is available on both GitHub and the Visual Studio Gallery.


Execution Policy in PowerShell Tools for Visual Studio

I’ve had several people report issues with PowerShell Tools for Visual Studio behaving differently than the NuGet console. After some investigation, I’ve found that NuGet actually resets the process scoped execution policy to RemoteSigned if it is not Unrestricted, RemoteSigned or Bypass.

This is taken from the NuGet source for the VSConsole.

      private static void SetupExecutionPolicy(RunspaceDispatcher runspace)
            ExecutionPolicy policy = runspace.GetEffectiveExecutionPolicy();
            if (policy != ExecutionPolicy.Unrestricted &&
                policy != ExecutionPolicy.RemoteSigned &&
                policy != ExecutionPolicy.Bypass)
                ExecutionPolicy machinePolicy = runspace.GetExecutionPolicy(ExecutionPolicyScope.MachinePolicy);
                ExecutionPolicy userPolicy = runspace.GetExecutionPolicy(ExecutionPolicyScope.UserPolicy);
                if (machinePolicy == ExecutionPolicy.Undefined && userPolicy == ExecutionPolicy.Undefined)
                    runspace.SetExecutionPolicy(ExecutionPolicy.RemoteSigned, ExecutionPolicyScope.Process);

My question is whether the community thinks this would be ideal for PowerShell Tools for Visual Studio as well. Currently, PoshTools is behaving like the ISE rather than NuGet. What do you think? Leave a comment or shoot me an email.

PowerShell Tools for Visual Studio Beta v0.5

If you haven’t seen the news, PowerShell Tools for Visual Studio is now available on the Visual Studio Gallery! The first beta brings with it many enhancements from alphas past and supports VS2013 RC. Here’s a quick overview of  the current state of the extension.


The current requirements for PoshTools are PowereShell v3 and Visual Studio 2012 or 2013RC. Several people have asked for VS2010 support and I’m researching the necessary changes. Also, there is a lot of interest in supporting VS2013 Isolated Shell. If the extension could be released in this manner it would make it completely free; just like the Python Tools for Visual Studio.

Editor Extensions

The extension adds language support to the Visual Studio editor. Some of the most important features are syntax highlighting, IntelliSense and code folding. IntelliSense with help you complete cmdlets and functions, variables and parameters. Code folding can collapse script blocks and comment blocks. Overall, syntax highlighting should be very similar to the ISE but there are known issues.


In addition to the basic functionality described above, the extension also adds support for the function navigation drop down bars on the top of editors. Using the v3 AST PowerShell API, I was able to discover the functions defined within the current file and present the navigation bars seen at the top of the editor window.

Function Navigation Drop Down

A big next step for the editor is snippet support but extensions do not support this; making it a bit tricky to implement. If you have a particular function you’d like you see in the editor, head over to GitHub.

Debugger Extensions

On top of the big changes to the editor there have also been some big changes to the debugger. The goal was the surpass the ISE in terms of debugging functionality. To accomplish this, I added support for the locals, break point and call stack windows.

The locals window shows all the variables in the current scope and enables the user to expand complex objects to dig down into the object. Just like when debugging other .NET languages, type information is provided. Next on the plate for the locals window is the ability to modify values at runtime. In addition to locals window support, I’m also looking at adding Watch window support.

Locals Window

Another key window when debugging is the break point window. It displays all current pending breakpoints that are set within all the open projects. Like any other break point, the file name and line number are provided. There is no support for conditional break points but would be a good feature to add in the future.

Breakpoints Window

Another important debugging window that is supported by PoshTools is the Call Stack window. Using the Get-PSCallStack cmdlet, the extension can display the current call stack when stepping or breaking in the debugger. There is currently no support for moving call stack frames and interrogating session state.

Call Stack Window

Finally, like with PowerGUI VSX, there is a project system dedicated to PowerShell. It’s been discussed to add different types of project systems for modules or generic collections of scripts but this isn’t currently the case. The extension exposes a project system that recognizes PSM1, PSD1 and PS1 files. In the current beta there is no support for automatic signing or manifest creation. There are dialogs created for this purpose but the MSBuild tasks and targets aren’t yet hooked into the project system.


Project System

I’d love to hear feedback about the current status of the extension. If you are trying it out please leave a review on the Gallery or enter any issues on GitHub.




The Future of PowerGUI VSX

PowerGUI VSX was released in June of 2010. Since then, it has received over 80,000 downloads between the Visual Studio Gallery and CodePlex. Over the past year, I have let the project slip. The last few versions didn’t even really add any new features but merely updated the version of PowerGUI they were compatible with. I’ve had a lot of requests for people to help out but haven’t seen any significant development on the project. One of the reasons this happened is that I knew I could do better. By embedding the PowerGUI editor directly in Visual Studio it caused a multitude of problems because it really wasn’t a true language integration but more like a hack.

Today, I’m highlighting a project that I’ve been working on and off for the last couple months. In the last week or so, I’ve dedicated some serious time to getting more parity between the current version of PowerGUI VSX and next major version. PowerGUI VSX v2 will offer true Visual Studio language support for PowerShell. It uses the Visual Studio editor and the raw PowerShell debugger, tokenizer and completion engine. Currently, the requirement is PowerShell v3 and Visual Studio 2012. This requirement may change depending on community support and adoption.

A lot of code has been taken from the current implementation of PowerGUI VSX. The project system remains the same. The skeleton for the debugging engine was harvested.

Finally, all the code can be found on GitHub. It offers a much better solution to social coding than CodePlex does. Check out the dev branch and fork me to add your own features.


Currently Implemented Features

Script Editor


Syntax Highlighting


Customizable Fonts and Colors



Breakpoint Support


Locals Support


Call Stack Support



Project System


PowerShell Project Template


Project Properties

PoshInternals – Multi Desktop Support

One really neat SysInternals tool is Desktops. It allows for managing several virtual workspaces, know as desktops on Windows machines. Unlike Linux that offers a builtin way to transfer between desktops, Windows does not natively expose a way to do so. The cmdlets added to PoshInternals now allow you to manage these virtual desktops right from the command line!

About Desktops

Desktops are little sandboxes of windows. Processes can be associated with a desktop and all windows drawn by that process will show up in that desktop. This allows you to declutter you main desktop into many desktops. Desktops are named entities and you can switch between them pretty easily once they are created. Simply creating a desktop doesn’t associate any processes with it. If you were to switch to a desktop without starting a process in it, you will see a blank screen. If you find yourself in this circumstance, you can access task manager and start processes that way.


Creates new desktops that are tied to the current Window Station. In most circumstances, this will be WinSta0 or the default Window Station. Window Stations contain one or more desktops and manage things such as the clipboard. For more information on Window Stations, check out MSDN. Desktops are limited by the desktop heap which, by default, is 48MB. By default, this cmdlet will start the explorer.exe process in the newly created desktop.


Returns the desktops that are associated with the current WinStation. The returned desktops are named and have a handle that is used to create processes in the desktop or show the desktop.


Activates the specified desktop as an interactive desktop. Again, it’s worth noting that if nothing was started in this desktop before showing it, you’ll have to use task manager to launch a process to work with in the desktop.

Start-Process Proxy Function

This proxy function adds the Desktop parameter to Start-Process. As expected, specifying the name of the target desktop will start the process in that desktop. One caveat with this method is that since PowerShell is a console application, if you just run PowerShell it will associate with the other desktop but input will still be taken on the current PowerShell window. This is due to how shared consoles work in Windows. To get around this and make a new PowerShell window, you can use the following command line.

Start-Process PowerShell -ArgumentList “& `”Start PowerShell`”” -Desktop Desktop2

Desktops is currently available in the dev branch of PoshInternals on GitHub. Check it out!

Here’s a video of it in action.

Interesting Side Note About Windows 8 and CreateDesktop

While creating the New-Desktop cmdlet I ran into an issue with Windows 8. Apparently, there currently exists a bug that will cause a BSOD from user mode code using CreateDesktop. I reproduced this on several Windows 8 machines with 100% consistency. The 5th parameter to CreateDesktop is the access mask used to specify security and access writes for the newly created desktop. I had a bug in my P\Invoke C# code that effectively was causing me to pass a $null as the access mask. This caused a BSOD everytime! It’s a little scary because it this function doesn’t require the process to be elevated. If anyone from Microsoft is curious at looking at the crash dump, here’s the analyze -v from WinDbg. I’ve also posted a simple example on PoshCode.

Getting Physical with PowerShell

PowerShell has historically been focused on managing servers’ software. With the implementation of the CIM cmdlets in v3, that changed quite a bit. See this module in particular to see how to manage hardware directly with PowerShell. Well there is another form of hardware manipulation that I wanted to expose some PowerShell support for. If you saw my previous blog post or my YouTube video, you can probably tell that I’m messing with some home automation hardware. Using the FluentDwelling project by Soapbox Automation, I’ve taken control of my brand new Insteon PowerLinc Modem and Dimmable Switch. This enabled me to create the app(s) in the video.

While testing my implementation, I needed a way to test the Insteon commands without the overhead of the entire system. To do this I harnessed PowerShell and made a simple module around the FluentDwelling API. I created a couple simple cmdlets to gain access to the PowerLinc modem and issue some basic commands against the light switch.

The first step is to get a hold of the modem. Use the Get-PowerlineModem specifying the PortName. Your system may be using a different port.


Next, you’ll have to get the device you want to manage. Every Insteon device comes pre-stamped with a unique DeviceId. The Get-Device cmdlet will return the devices that are currently in the modem’s database. This database is sync’d from the management software called HouseLinc provided by Insteon. There are two devices with the same Id because the device supports bi-direction communication. It can inform the modem that someone has turned on the light switch manually.


Finally, you can set the state of the light. Just pass in one of the devices returned by Get-Device and set the State property. Right now this cmdlet supports On and Off along with dimmable light ramping. Ramping a light causes it to turn on or off gradually rather than right away. When you ramp on, you can specify the dim value. This can be between 1-255. By default it’s set to 128 or about 50%.



I’ve uploaded the current module to GitHub. If you have any Insteon or X10 devices feel free to fork me. I probably won’t be adding new devices to the module until I actually get some new ones as it’s pretty hard to test the cmdlets without the compatible device. ;)

Home Automation – Step 1 – Infrastructure

I’ve always been enamored with the idea of home automation. It seems so obtainable with a little dedication and some know how. I’ve done lot’s of research and actually posted awhile back about what I was planning. Well I’ve moved the idea along a bit further and actually have the basic infrastructure setup. Not to long ago I “finished” my basement. Installed a bar, pool table room, projector, the works! Now that I have a real life movie theater room, I wanted to toy with the ability to control the entire setup from my phone…with my voice. Below outlines the basic composition of software and hardware I’m using to achieve this.


It’s a simple mashup of technologies that made it pretty easy to quickly throw together. I repurposed my media PC as the controlling machine for the whole system. I even reused my old CRT. I knew I kept it for a reason.


The Android app is a very, very basic Speech to Text implementation that utilizes the RecognizerIntent. It simply translates the voice to text and passes it along to my web server. On my web server I’m running DynDns to ensure that I have a consistent URI to target. This means I can push commands to my house from anywhere.

The WebAPI is nothing more than a pass through. Since I need the actual controller to run in a full user’s desktop and not the service desktop, I have IIS push the command through to the WCF endpoint.

The controller itself is pretty simple and is primarily tasked with composing the numerous modules that do the actual work. Each module is composed of zero to many Feedback, Task or InputSensor implementations that handle the three types of I\O the system can generate or receive. Each module can determine if it can process a particular type of input and then provide feedback or execute a task based on that input. One of the more interesting modules is the IR module.

The IR module’s purpose is to transmit IR messages to different pieces of stereo equipment in the basement. With a simple voice command I hope to control the receiver, projector, DirecTV and bluray player. For instance, it would be great to say “I want to watch the SciFi channel.” This would turn on the projector, receiver and DirectTV box and change the channel to 244, set the volume to a reasonable level and dim the lights.

Inside the IR Module

The IR module consists of two pieces of third-party software and one piece of hardware. The hardware is an IguanaWorks USB Transceiver.

It can translate and emit IR signals. The idea is that the transceiver can record remote control button presses and then create a map of the remote that it can then playback programmatically. The first piece of software that is required is the driver for the transceiver and “IR Daemon”. They allow Windows to correctly communicate with the transceiver. I had to reach out to the guys at IguanaWorks to get a test version of their Windows 8 driver but it worked like a charm.

Next, I needed to install WinLIRC. WinLIRC is a port of the Linux Infrared Remote Control project. It is what actually translates the IR data into a map of remote control commands and provides the functionality to play back those button presses through the transceiver. My IR module will communicate with WinLIRC to press the correct button combinations to control the various devices in the basement.

Inside the Insteon Module

Another important module is the Insteon module. Insteon makes power line-based home automation controls. This type of home automation device uses existing power lines to communicate commands to the different nodes. Think of light switches or outlets. There is no need to run additional wires since the commands will be coming through the very wires delivering power. Insteon’s communication mechanism is more robust than the older X10 protocol that uses the same facility. I hope that the newer power lines in my basement will provide adequate noise protection so that communication doesn’t get scattered which can happen with older power lines.

The Insteon module will harness the FluentDwelling project by SoapBox Automation. This C#  API interfaces with Insteon to provide easy access to the devices hooked up the system. I hope to be able to dim, turn on and off the lights. I could also check from my phone whether I left the lights on in the basement!

Next Steps

Currently, I only have the IR module controlling a small TV in my office. I need to mount the transceiver and begin controlling the different components in the basement. I also need to install the Insteon controller and light switch when they arrive.

When I feel like splurging, I am considering buying a Nest thermostat or something similar. This will allow me to manage the temperature in my house from wherever I am.

Finally, I think it’s pretty important I write a PowerShell module to control and debug the system. ;)

Testing ASP.NET MVC4 Web API Endpoints with PowerShell

PowerShell v3 added some very useful web cmdlets that make working with web services and pages much easier. In previous versions, it was common practice to use the WebClient class but this wasn’t straight forward in the least bit. Recently, I’ve been working with ASP.NET MVC4 Web API and found that the new additions to PowerShell to be extremely handy. Here are a couple techniques to make working with the cmdlets against Web API a pleasant experience.

The Invoke-RestMethod Cmdlet

The Invoke-RestMethod cmdlet is very easy to use. That’s my favorite part. It’s much easier than using Fiddler or Curl and it’s installed right out of the box. I did another blog post about how to use the cmdlet to access Reddit APIs and pull down the hot posts in a Subreddit. Aside from invoking the GET verb, the Invoke-RestMethod cmdlet has a Method parameter that accepts any of the HTTP verbs as fodder. This enables for PUTs, POSTs, DELETEs oh my!.

A Simple Web API

Assume that I have a simple CodeMonkey class with a couple basic properties.



My Web API is also very simple. It exposes a GET, PUT, POST and DELETE.


Accessing Code Monkeys

By default, the Invoke-RestMethod uses the GET verb and will retrieve entities from the API. Invoke-RestMethod also converts JSON directly into PowerShell objects that can be piped to all your favorite formatting and processing cmdlets.



Just as easily, we can grab a single monkey by tacking on the Id in a very RESTful manner.



Since the objects coming back to the pipeline are PSCustomObjects, we have the ability to use cmdlets like Select-Object to process the returned data. There is a caveat when piping collections of objects returned by this cmdlet. You may notice that using cmdlets like Select-Object and Where-Object don’t behave as expected. You’ll have to use the GetEnumerator method of the list that is returned in order to actually access the inner objects and process them as expected.


Posting New Code Monkeys

In addition to getting entities, the Invoke-RestMethod cmdlet can easily modify them as well. Since the Invoke-RestMethod cmdlet can invoke PUT and POST requests, it is necessary to serialize data in a way that the Web API will find meaningful. To accomplish this, we can use a combination of PowerShell hashtables and the new ConvertTo-Json cmdlet. It’s as simple as creating a hashtable that matches your data transfer object, converting it to a JSON string and passing it to the Body parameter of Invoke-RestMethod.



While using Web API, it’s important to use the correct content type. I struggled quite a bit with this in the beginning. If you don’t set the content type to application/json, the request will have an application/x-www-form-urlencoded content type and the Web API won’t know what to do with it. I saw some very strange behavior. Null CodeMonkeys or CodeMonkeys without properties set!

Updating Existing Code Monkeys

Just like when POSTing new code monkeys to the API, we can also PUT, or update, existing code monkeys. This is accomplish almost exactly the same way as a POST with only a change to the Method and the URI that we specify.



Removing Code Monkeys

Equally as easy is deleting existing monkeys. No need for a body here. We only need to specify the Delete method and the Id.



Nested Object Support

Web API, Invoke-RestMethod and ConvertTo-Json support nested objects. Keep in mind that the ConvertTo-Json and ConvertFrom-Json cmdlets have a Depth property. By default, these cmdlets will serialize 3 levels deep. To create nested objects, just create a hash table that matches the format of your data transfer object and convert it to JSON. Web API will happily deserialize it if it matches the new DTO. Also notice the support for arrays of objects.



Why should I use this to test my Code Monkeys? 

This is just another tool in the toolbox for developers or admins alike to easily access web services. What I find especially appealing is the close similarities in the JSON and PowerShell hashtable syntax. It really helped me to visualize how my data would be sent across the wire. Being in PowerShell, I found it extremely flexible to quickly modify the data or request. I haven’t found an easier way to consume a web service!

So what do you think? Could you use this technique to conquer your Code Monkeys?


Subscribe to RSS Feed Follow me on Twitter!