Vote for CodeStock 2012 Content

§ February 29, 2012 16:28 by beefarino |

imageIt’s that time of year again.  The voting for CodeStock sessions has been opened!  Looking over the list of possible talks, I’m really excited and highly encourage you to go if you can.  CodeStock was my first conference and speaking experience, and I can’t help but think it is a huge part of why I enjoy speaking so much.

And while we’re on the topic, I’d really appreciate you voting for my sessions this year.  I’m changing things up a bit, a reflection of my changing priorities and attention.  Oh, I have PowerShell sessions, don’t worry.  Two in fact:

However I’ve also submitted two sessions of a different ilk.  The first is part of my 2012 resolution to learn various maker-craft, such as crochet, robotics, electronics, etc.  Fun with Lilypad! promises to be a unique and engaging session.  I mean seriously, how often can you say you saw someone program their hat?

The other session is a group panel on Raising the Next Generation of Geeks.  I want parents to share their experiences of fostering the geek in their children – what works, what doesn’t, what the major obstacles are.  I want to hear about projects you do with your kids that sparked the fuse on their nerd-bomb…

If you plan to attend and think you’d like to experience one or more of these sessions, then I humbly ask for your vote.

Upcoming Speaking Engagements

§ February 24, 2012 13:00 by beefarino |

Just a quick note about two upcoming speaking engagements where you’ll have the chance to soak up some PowerShell love.

In mid-March I’ll be presenting Stupid PowerShell Tricks for the .NET Developer at CodePaLOUsa.  If you write .NET code – be it for the web, the enterprise, or a device – I’ll show you how PowerShell can make mincemeat out of large, boring, and repetitive tasks.  In addition I’ll be showing off how I’ve personally integrated Mercurial and Git into PowerShell, how I use PowerShell to drive my software build process (including running remote tests), and how I automate massive changes to my source code.

Then on April 14 I’ll be in Atlanta for SQL Saturday #111, where I’ll discuss PowerShell Modules you Should Know About.  If you’re new to PowerShell, this will be a great session to attend as it will show off a wide diversity of the things that PowerShell can do – from database management to simple UI to spooling Hyper-V virtual machines. 

I’m looking forward to both of them, and I hope to see you there!

All About the Recent Downtime

§ February 24, 2012 10:34 by beefarino |

downtimeSo the last few weeks have been a rollercoaster for  I apologize if the downtime has affected your powershelling or log4netting or whatever.  I’m hoping the troubles are behind me…

So here’s what happened.  Late last year I updated the backend of beefycode to the most recent version of which required me to update my hosting situation to a server that supports ASP.NET 4.  Apparently I was the last person on earth to do this and received a rude awakening as my new shared server seemed to be VERY shared.  Accessibility of this blog became and issue so I wanted to move it to another shared host I was using that seemed much more reliable.  So I did that.

Things were fine for a few weeks, and then my host suspended my account for “CPU abuse”.  Apparently was spiking the CPU usage to as high as 99%, so they had no choice.  The logs showed nothing unusual, and I was unable to replicate the scenario locally so was a bit blind as to what tactic to take, but I tried a few things.  It didn’t help as the host suspended my account again and refused to reactivate it unless I upgraded to a VPS.  I was miffed – I couldn’t event access FTP with my account suspended and had no choice but to move the blog to another host so I could get my other sites back online.  But I understand their stance – they gave me several chances to address the issue and I failed to do so, so they did what they did to protect their other customers.

Thankfully OrcsWeb provides complimentary hosting accounts for MVPs, so now is hosted there.  I poured a few days into porting the blog to Orchard; unfortunately this time was wasted.  The hosting account limits the virtual memory for the application pool to 600MB, recycling the application pool when it exceeds this value.  I personally thing 600MB is plenty; however, I can’t host the default Orchard site without it spiking this on each and every page view.  That’s right – one application pool recycle per page view.  It was completely unusable - sluggish and nonresponsive.  So I’m back to  Hopefully updating to a more recent (and less customized) theme will tamper the CPU use, otherwise I may be looking into a VPS after all…

StudioShell 1.2 Release

§ February 23, 2012 10:24 by beefarino |

image_thumb1_thumbA bit late to the blog, but I’m happy to say that StudioShell 1.2 has been released! This release has been a long time coming, due largely to my lack of focus and a rather ambitious feature set.

This post is a breakdown of the key elements in the 1.2 release. I’ll elaborate more on some of these items in future posts.

NuGet Support

While I prefer the StudioShell console experience over NuGet, NuGet has a user base that is 170 times larger than StudioShell. It’s silly not to do everything I can to support that environment – both in terms of enabling StudioShell features in the NuGet host and in leveraging the NuGet distribution mechanism.

In the previous releases, the majority of StudioShell features were available from the NuGet console; however, some of the more “luxurious” features wouldn’t work – for instance, you could add menu commands from the NuGet console:

1 PM> new-item dte:/commandbars/menubar/help ` 2 -name clickthis -value {"hello world!" | out-host}

The “clickthis” menu item would appear, but it wouldn’t do anything when you clicked on it. The 1.2 release addresses these shortcomings – you can now expect full support for StudioShell functionality from the NuGet package manager console.

In addition, you can now install StudioShell via NuGet. Just search the public repository for the “StudioShell” package:

1 PM> install-package StudioShell

PowerShell Support

One of the most frequent requests I receive is to use StudioShell from the standard PowerShell console. This would be a great enabler for automated build scenarios and software factories.

This is now possible with the 1.2 release. You can pull StudioShell into your standard PowerShell console just like any other module:

1 > import-module StudioShell

This results in a DTE: drive that is attached to a new instance of Visual Studio that you can use to load solutions, edit projects, create code, etc.

Experimental SSMS Support

A friend of mine is interested in using StudioShell in other Visual Studio shell applications – specifically in BIDS. We haven’t gotten that far, but the StudioShell 1.2 MSI installer does allow you to integrate with SQL Server Management Studio 2012 (Denali).

Not all of the DTE: drive is available – in particular the project and code models don’t seem to be supported in SSMS. At the same time, there is still a lot of useful functionality available. E.g., the debugger hive is fully functional, allowing you to spelunk stacks, locals, etc. during a SQL debugging session.

This feature should be considered highly volatile until we can get some people using it regularly and reporting the issues. Use at your own risk.

DTE: Drive Topology

In the past year I’ve learned quite a bit about designing useful PowerShell providers. I’ve applied some of this knowledge to the StudioShell PSDTE provider by changing the layout of some of the drive nodes.

In previous releases the code model and project model occupied a shared space on the DTE: drive. This made sense from an object-model perspective – projects contain files, files contain code. Unfortunately it made for some slow pipelines; for instance, applying global code changes:

1 ls dte:/solution -rec | ` 2 where {$_ -match 'codeclass' } | ` 3 set-itemproperty -name Comment -value (get-date)

would force iteration of all project items, properties, and code. Very slow operation during which the shell and Visual Studio remain unavailable. The new drive topology moves the code model to a peer of the project model:

1 ls dte:/solution/codemodel -rec | ` 2 where {$_ -match 'codeclass' } | ` 3 set-itemproperty -name Comment -value (get-date)

effectively isolating code from projects and enabling faster “bulk” operations.

These changes are breaking for existing scripts that rely on the old path topology, but 1.2 includes a simple way to revert the drive topology to the previous version when you need to:

1 > use-pathTopologyVersion 1.0

In a nutshell, this command tells the PSDTE provider to use the drive topology that existed in the specified version of StudioShell. If you have a script that relies on these old paths, just add a call to use-pathTopologyVersion to the top of the script and StudioShell will re-enable the old paths. When you’re done, you can bounce back to the current topology just as easily:

1 > use-pathTopologyVersion -current

Cleaner Codebase

StudioShell started as a very … organic project. It grew as I needed it to grow, and it still does. As a friend once understated, “it’s a bit monolithic.” The code needed some serious refactoring before any of the previous features could be realized.

A quick shout-out to two vendors who proved key in this process: NDepend was essential in teasing apart concerns, and PostSharp greatly simplified several feature implementations.

Bug Fixes

Of course this release contains plenty of fixes as well. A special thank-you to everyone who supports this project by submitting issues and discussing features. Keep ‘em coming.

Looking Ahead – looking for help

So what’s next for StudioShell? First and foremost is a more aggressive release pipeline. With 1.2 comes a PSake build, the next step is to incorporate automated deployments to NuGet and CodePlex. I don’t want to wait another 6 months to package a release.

I’m also looking at expanding the DTE drive topology to include some other Visual Studio services. More on this later.

I’d also like some help getting StudioShell usable in other shells, especially the SQL family of Visual Studio shells. If you have the inkling to help, please get in touch.