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.