StudioShell 1.6 Supports VS 2013

§ January 28, 2014 23:18 by beefarino |

ohaiGreat news for StudioShell lovers…

This evening I pushed a new build of StudioShell that includes support for Visual Studio 2013.  The new build is available through the usual channels:

  • Download the installer from CodePlex
  • Install using NuGet or Chocolately
  • Clone the code and invoke the install psake task:
hg clone  https://hg.codeplex.com/studioshell
cd studioshell
import-module psake
invoke-psake install

As always, report any issues or requests using the Issue Tracker.

Happy coding!



Manipulating the AppDomain of your PowerShell Session

§ January 17, 2014 15:21 by beefarino |

imageEarlier this week I pushed a new project to my public github repositories.  This project contains a PowerShell module that enables you to change the active configuration of the appdomain that is hosting your PowerShell session.  I’ve been asked a lot of questions about what this does exactly, and why someone would want to use it.  This goal of this post is to clarify the scenario where this is useful.

TL;DR: if you have to ask, you don’t need it.

Let’s say you want to use a .NET library that relies on one or more settings in the application configuration file.  Like what?  Well, let’s say you need to add a connection string to the appdomain configuration to get a library that uses Entity Framework to work correctly.   In fact, that’s where this project came from – I needed a way to manipulate connection strings in the app domain configuration to get Entity Shell to work properly.

In order to leverage such a library from PowerShell, you’ll need to modify the application configuration file for the PowerShell application, which is really bad form.  Seriously.  Don’t do that.  That file isn’t for you.  Stop touching it.  Sit on your hands if you have to.

Another alternative is to make a copy of the entire PowerShell application, with its own configuration file, and then edit the copy.  That’s silly.  Seriously.  Don’t do that.  No one wants multiple copies of the same application laying about.  No one I say!  So just remove-item –recurse –force all those duplicate powershell.exe applications, okay? 

And yet another alternative – and this was my preferred path until recently – was to use a tool called poshrunner from friend and coastal neighbor Justin Dearing.  This little gem would help you spool up a new app domain using a specific configuration file, so a script could take advantage of the new configuration.  I still like this approach, and it works really well as long as you’re willing to plan ahead a little bit.  Which I’m not.  I tend to find myself in a PowerShell session filled with state and variables that I want to keep using.  Poshrunner was hard to fit into this gambitesque workflow.

So I found an alternative way.  A way you can manipulate app settings and connection strings for the active PowerShell session.  Here’s an example using this new module to configure a connection string in the active PowerShell session:

> import-module appDomainConfig
> add-connectionString -name 'UserGroupContext' `
  -provider 'System.Data.SqlClient' `
  -connectionstring 'Data Source=.\SQLExpress;Initial Catalog=SuperAwesomeWebsite.Models.UserGroupContext;Integrated Security=True'

Name                    : UserGroupContext
ConnectionString        : Data Source=.\SQLExpress;Initial ...
ProviderName            : System.Data.SqlClient
LockAttributes          : {}
LockAllAttributesExcept : {}
LockElements            : {}
LockAllElementsExcept   : {}
LockItem                : False
ElementInformation      : System.Configuration.ElementInformation
CurrentConfiguration    :

Pretty simple, eh?  No fuss, it just works.  Your PowerShell session isn’t disrupted, and the configuration change sticks for the remainder of your session without being persisted to any file. 

So far the module supports adding, getting, and removing app settings and configuration strings.  More features may be added if I find I need them (or you can send a pull request with your own changes).

How it Works

It cheats. 

Well sort of.  It uses .NET reflection to manipulate the configuration type private members and gain write access to the configuration bits for the current app domain.

Isn’t that dangerous?  I guess.  Well, I mean, in the grand scheme of things, this is a pretty safe thing to do.  We’re not naked soaring on a flaming hang-glider over sharks-with-lasers-infested waters during an air-to-air battle with zombie-piloted Messerschmitts.  You might be able to muss up your app domain configuration, but I haven’t crashed the process yet.

Isn’t that fragile?  I guess.  Well, I mean, that API has been around for a long time.  And this is a technique I’ve been using for about 8 years now.  And it still works.  And if it stops working then I suppose I’ll take another look at it.  I mean, how fragile could it be?  “The code’s only been working for EIGHT years!”

Isn’t that bad practice?  I guess.  Well, I mean, I personally think the configuration API should have a programmatic interface as well as the XML one.  That’s the bad practice in my mind.  I’m just taking corrective measures so I can use it the way I need to use it to get my work done.

Isn’t that …. Look, if this sort of thing leaves a bad taste in your mouth, then please offer an acceptable alternative.

In the meantime, I would suggest you give the module a whirl if you think it would help you.



A Month of User Group Activity

§ January 12, 2014 17:11 by beefarino |

stockvault-dog-sleeping-in-bed131802I just got back from CodeMash, and my brain is full of project ideas and new-to-me information that I’m still trying to digest.  More on that later.  I’ve managed to stick my head out of the covers long enough to look at my calendar for the next four weeks, and it’s chock full of speaking engagements I wanted to let you know about.

First up, we have a virtual presentation for the Mississippi PowerShell User Group on Tuesday, January 14 at 9:30pm ET.  This will be an online presentation, but you’ll need to register to attend.  The topic for the evening is PowerShell Gotchas! –  this is a talk derived from my Pluralsight course of the same name, and the abstract for the talk is available below.

Next week is a two-fer!  I’ll be giving the PowerShell Gotchas! talk to the Florida PowerShell User Group on January 21 at 6:30pm ET.  This is another online presentation for which you’ll need to register

And then on January 23rd I’ll be in Alpharetta for the Atlanta PowerShell User Group – space is limited for this live event so be sure to register if you plan to attend.

And finally, I’ll be participating in PowerShell Saturday #007 on February 8.  This event is stacking up to be a great one – fantastic speakers and fantastic content and fantastic fun.  I’ll be running a double-oh-seven-spy-themed Iron Scripter! competition as well as presenting on PowerShell Gotchas!.  Space is limited and tickets are going fast, so if you’re interested in this all-day event please register soon.

Whew.  That’s a lot of speaking.  And it’s not over then.  Later in February I’ll be presenting to the Microsoft Integration Architects (again in Atlanta) about message-based application architectures.  And in April, I’ll be giving three sessions of new content at the PowerShell Summit North America.

Sweet Georgia Brown, I must be insane. 

PowerShell Gotchas!

PowerShell is the de facto standard for automation and administration on Windows systems.  The central design mantra in PowerShell is Think-Type-Get.  That is: Think what you want, Type it, and Get the results.  Unfortunately this mantra tends to break down - PowerShell combines concepts from other languages (Perl, Python, and VBScript for example) and borrows ideas from other platforms (like pipelining in Bash).  This creates an experience that feels familiar, but fails to behave consistently with our experiences.  This creates "gotchas".  In this talk we will analyze some specific cases of PowerShell's strange behavior in order to better understand how and why PowerShell works the way it does.