May 162013
 

PowerGUI_Badge_SeeYouAtFollowing on from the last instalment where I looked at supporting PowerShell script development in Visual Studio 2010, I’m going to take a closer look at PowerShell integration with the newer Visual Studio 2012.

Again, I’ll be leveraging the excellent Quest PowerGUI product and the associated Visual Studio extension.

Installation

You’ll also need PowerGUI 3.2, but this time there’s an updated Visual Studio extension which you’ll need, version 1.6.1

Install PowerGUI 3.2 first, and once complete then install the Visual Studio extension.  PowerGUI has a dependency on the .NET Framework 3.5, on newer OSes (like Windows 8) you might not have this pre-installed, don’t worry – the installer will warn you if anything’s missing.

Getting Started

Once you’ve installed, you will see a new option in Visual Studio’s File –> New Project dialog for PowerShell.  This creates a fairly sparse new project with a .ps1 file in it ready to go.

Troubleshooting

The first two times I tried to get everything installed and running, I kept getting issues with Visual Studio 2012 warning it couldn’t load PowerGUI.  I tried everything until I realised what the problem was.  I’d downloaded the .vsix but one thing finally dawned on me:

image
Unblock

Therefore, unblocking the file before installing seemed to do the trick.  If you’re having problems loading the extension this might be a problem for you as well.

Looking at the Project

As with Visual Studio 2010, you get the PowerShell project type available in the New Project dialog:

image
New Project

A closer look

Some of the advantages of using Visual Studio to write your PowerShell scripts are easy to highlight.  The debugging support is obviously a huge advantage, but so to is the Intellisense support. 

It’s really evident when there’s an issue with the script, if you aren’t seeing the right info in Intellisense.  Rather than go into detail, they say a picture is worth a thousand words, so let’s see some examples of the value in writing your PowerShell scripts in Visual Studio:

image
Debugging Support

image
IntelliSense Support

image
PowerGUI integrated Console

image
Best of all – Tooltips which provide CmdLet syntax

What’s Next?

Now that we’ve explored both Visual Studio 2010 and Visual Studio 2012 options for PowerShell, the next step is to take a look at some of the advantages of using either environment when building your PowerShell scripts.  We’ll also look at trace/output options and how to best handle errors.

Check back for the next article..soon.

Feb 192013
 

Recently, I had to authenticate to Team Foundation Server using an account with greater permissions to perform some administrative tasks.  As you may know, this requires entering alternate credentials when you add the server to the list of TFS servers, or when you need to connect to the server.  Once you’ve connected once, you aren’t prompted again as the credentials are cached locally.

In the past, to remedy this, you could simply delete the local TFS cache, which is located in the following directory (Windows Vista and onwards):

<system drive>\Users\<your profile>\AppData\Microsoft\Team Foundation

image

However, in more recent versions this has changed somewhat, and the user’s credentials are no longer linked to the local TFS cache or configuration.

Where are the Credentials?

Good question.  After some digging about, it seems that the credentials are now stored in the user’s Credential Manager store within Windows.  If you aren’t familiar with this, it was introduced on the more recent versions of Windows, and it lives via the Control Panel, under the following path: Control Panel->User Accounts

image

Inside this location, you can view all the locally cached credentials, including Windows Credentials:

image

Note: that it appears that for TFS credentials used by Team Explorer and other applications, the credentials are the ones under “Generic Credentials” not under “Windows Credentials” (in case you have TFS entries in both).

Making Changes

To modify or remove the credentials you use to connect to TFS, simply expand the appropriate entry and click on “Edit”, or to delete the local credentials, click on “Remove”.  If you opt to remove the credentials, you’ll be prompted to enter new credentials next time you connect to the specified TFS server.

image

 

So that was a little out of the way. When I tested this, I made sure that I’d disconnected from TFS before changing/removing the credential configuration.

It would be nice if Team Explorer linked to the Credentials Manager so we didn’t have to go digging to work this out, wouldn’t it?